From owner-freebsd-net@FreeBSD.ORG Sun Nov 12 04:12:58 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 E650116A407; Sun, 12 Nov 2006 04:12:58 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 92A4543D60; Sun, 12 Nov 2006 04:12:58 +0000 (GMT) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id kAC4CvxL001660; Sat, 11 Nov 2006 23:12:57 -0500 (EST) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.6/8.13.3) with ESMTP id kAC4CuIB035746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Nov 2006 23:12:56 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <200611120412.kAC4CuIB035746@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 11 Nov 2006 23:13:05 -0500 To: Scott Long From: Mike Tancsa In-Reply-To: <455570D8.6070000@samsco.org> References: <2a41acea0611081719h31be096eu614d2f2325aff511@mail.gmail.com> <200611091536.kA9FaltD018819@lava.sentex.ca> <45534E76.6020906@samsco.org> <200611092200.kA9M0q1E020473@lava.sentex.ca> <200611102004.kAAK4iO9027778@lava.sentex.ca> <2a41acea0611101400w5b8cef40ob84ed6de181f3e2c@mail.gmail.com> <200611102221.kAAML6ol028630@lava.sentex.ca> <455570D8.6070000@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: freebsd-net , freebsd-stable@freebsd.org, Jack Vogel Subject: Re: Proposed 6.2 em RELEASE patch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Nov 2006 04:12:59 -0000 At 01:42 AM 11/11/2006, Scott Long wrote: driver. What will help me is if you can hook up a serial console to >your machine and see if it can be made to drop to the debugger while it >is under load and otherwise unresponsive. If you can, getting a process >dump might help confirm where each CPU is spending its time. ./netblast 192.168.88.218 500 110 1000 I compiled in the various debugging options and on the serial console I get a few Expensive timeout(9) function: 0xc0601e48(0) 0.024135749 s and the serial console telnet> send break Expensive timeout(9) function: 0xc0561444(0xc63f1d80) 0.072485748 s KDB: enter: Line break on console [thread pid 27 tid 100017 ] Stopped at kdb_enter+0x2b: nop db> db> ps pid ppid pgrp uid state wmesg wchan cmd 1206 1123 1206 0 R+ ifstat 1155 1154 1155 0 R+ csh 1154 1 1154 0 Ss+ wait 0xc6722218 login 1123 1122 1123 0 S+ pause 0xc6722894 csh 1122 1117 1122 1002 S+ wait 0xc6739430 su 1117 1116 1117 1002 Ss+ pause 0xc6aa024c csh 1116 1114 1114 1002 R sshd 1114 1028 1114 0 Ss sbwait 0xc6893370 sshd 1112 1 1112 0 Ss+ ttyin 0xc65ba810 getty 1111 1 1111 0 Ss+ ttyin 0xc65bac10 getty 1110 1 1110 0 Ss+ ttyin 0xc65bb010 getty 1109 1 1109 0 Ss+ ttyin 0xc65bc410 getty 1108 1 1108 0 Ss+ ttyin 0xc65b4010 getty 1107 1 1107 0 Ss+ ttyin 0xc65bd010 getty 1106 1 1106 0 Ss+ ttyin 0xc65bcc10 getty 1105 1 1105 0 Ss+ ttyin 0xc65b2010 getty 1044 1 1044 0 Ss nanslp 0xc076ecac cron 1038 1 1038 25 Ss pause 0xc6ab2aac sendmail 1034 1 1034 0 Rs sendmail 1028 1 1028 0 Ss select 0xc07bc004 sshd 898 1 898 0 Ss bo_wwait 0xc6ac9130 syslogd 846 1 846 0 Ss select 0xc07bc004 devd 445 1 445 65 Ss select 0xc07bc004 dhclient 425 1 43 0 S+ select 0xc07bc004 dhclient 124 1 124 0 Ss pause 0xc6739034 adjkerntz 42 0 0 0 SL - 0xe8ff9d04 [schedcpu] 41 0 0 0 SL sdflush 0xc07c50f4 [softdepflush] 40 0 0 0 RL [syncer] 39 0 0 0 RL [vnlru] 38 0 0 0 SL psleep 0xc07bc56c [bufdaemon] 37 0 0 0 SL pgzero 0xc07c6064 [pagezero] 36 0 0 0 SL psleep 0xc07c5bb4 [vmdaemon] 35 0 0 0 SL psleep 0xc07c5b70 [pagedaemon] 34 0 0 0 WL [irq1: atkbd0] 33 0 0 0 WL [irq7: ppc0] 32 0 0 0 WL [swi0: sio] 31 0 0 0 RL [acpi_cooling0] 30 0 0 0 SL tzpoll 0xc08cd838 [acpi_thermal] 29 0 0 0 WL [irq19: bge1] 28 0 0 0 WL [irq16: bge0+] 27 0 0 0 RL CPU 1 [irq18: em1] 26 0 0 0 WL [irq17: em0] 25 0 0 0 WL [irq23: nve0] 24 0 0 0 WL [irq22: atapci2] 23 0 0 0 WL [irq21: atapci1] 22 0 0 0 WL [irq15: ata1] 21 0 0 0 WL [irq14: ata0] 20 0 0 0 WL [irq9: acpi0] 9 0 0 0 SL - 0xc645f080 [kqueue taskq] 19 0 0 0 WL [swi2: cambio] 8 0 0 0 SL - 0xc645f280 [acpi_task_2] 7 0 0 0 SL - 0xc645f280 [acpi_task_1] 6 0 0 0 SL - 0xc645f280 [acpi_task_0] 18 0 0 0 WL [swi5: +] 5 0 0 0 SL - 0xc645f400 [thread taskq] 17 0 0 0 WL [swi6: Giant taskq] 16 0 0 0 WL [swi6: task queue] 15 0 0 0 RL [yarrow] 4 0 0 0 RL [g_down] 3 0 0 0 RL [g_up] 2 0 0 0 RL [g_event] 14 0 0 0 WL [swi3: vm] 13 0 0 0 RL CPU 0 [swi4: clock sio] 12 0 0 0 WL [swi1: net] 11 0 0 0 RL [idle: cpu0] 10 0 0 0 RL [idle: cpu1] 1 0 1 0 SLs wait 0xc63f5000 [init] 0 0 0 0 WLs [swapper] db> db> show intr irq1: atkbd0 (pid 34) irq4: sio0 (no thread) irq7: ppc0 (pid 33) irq9: acpi0 (pid 20) irq14: ata0 (pid 21) {ENTROPY} irq15: ata1 (pid 22) {ENTROPY} irq16: bge0+ (pid 28) irq17: em0 (pid 26) irq18: em1 (pid 27) irq19: bge1 (pid 29) irq21: atapci1 (pid 23) {ENTROPY} irq22: atapci2 (pid 24) {ENTROPY} irq23: nve0 (pid 25) swi1: net (pid 12) {SOFT} swi4: clock sio (pid 13) {SOFT, NEED} swi3: vm (pid 14) {SOFT} swi6: task queue (pid 16) {SOFT} swi6: Giant taskq (pid 17) {SOFT} swi5: + (pid 18) {SOFT} swi2: cambio (pid 19) {SOFT} swi0: sio (pid 32) {SOFT} db> db> show pcpu cpuid = 1 curthread = 0xc63f2900: pid 27 "irq18: em1" curpcb = 0xe500dd90 fpcurthread = none idlethread = 0xc63f1600: pid 10 "idle: cpu1" APIC ID = 1 currentldt = 0x50 spin locks held: exclusive spin mutex sio r = 0 (0xc07c81c0) locked @ /usr/src/sys/dev/sio/sio.c:1390 db> db> show intrcnt irq4: sio0 901 irq14: ata0 1425 irq16: bge0+ 35 irq17: em0 33705 irq18: em1 26846 irq19: bge1 2001 irq21: atapci1 42 irq22: atapci2 33 cpu0: timer 2834932 cpu1: timer 2826571 db> db> show irqs irq0: (no thread) irq1: atkbd0 (pid 34) irq3: (no thread) irq4: sio0 (no thread) irq5: (no thread) irq6: (no thread) irq7: ppc0 (pid 33) irq8: (no thread) irq9: acpi0 (pid 20) irq10: (no thread) irq11: (no thread) irq12: (no thread) irq13: (no thread) irq14: ata0 (pid 21) {ENTROPY} irq15: ata1 (pid 22) {ENTROPY} irq16: bge0+ (pid 28) irq17: em0 (pid 26) irq18: em1 (pid 27) irq19: bge1 (pid 29) irq20: (no thread) irq21: atapci1 (pid 23) {ENTROPY} irq22: atapci2 (pid 24) {ENTROPY} irq23: nve0 (pid 25) db> Let me know if there is anything else you want me to print out From owner-freebsd-net@FreeBSD.ORG Sun Nov 12 09:40:15 2006 Return-Path: X-Original-To: freebsd-net@hub.freebsd.org Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B189B16A412; Sun, 12 Nov 2006 09:40:15 +0000 (UTC) (envelope-from gnn@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2EBA443D4C; Sun, 12 Nov 2006 09:40:15 +0000 (GMT) (envelope-from gnn@FreeBSD.org) Received: from freefall.freebsd.org (gnn@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id kAC9eFKn039963; Sun, 12 Nov 2006 09:40:15 GMT (envelope-from gnn@freefall.freebsd.org) Received: (from gnn@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id kAC9eEBg039959; Sun, 12 Nov 2006 09:40:14 GMT (envelope-from gnn) Date: Sun, 12 Nov 2006 09:40:14 GMT From: "George V. Neville-Neil" Message-Id: <200611120940.kAC9eEBg039959@freefall.freebsd.org> To: kostya@tessart.kiev.ua, gnn@FreeBSD.org, freebsd-net@FreeBSD.org Cc: Subject: Re: kern/52585: [netinet] [patch] Kernel panic with ipfw2 and syncookies X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Nov 2006 09:40:15 -0000 Synopsis: [netinet] [patch] Kernel panic with ipfw2 and syncookies State-Changed-From-To: suspended->closed State-Changed-By: gnn State-Changed-When: Sun Nov 12 09:39:29 UTC 2006 State-Changed-Why: This can no longer be reproduced (7.0 CURRENT) http://www.freebsd.org/cgi/query-pr.cgi?pr=52585 From owner-freebsd-net@FreeBSD.ORG Sun Nov 12 11:07:17 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 CD65F16A417; Sun, 12 Nov 2006 11:07:17 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from server.t-hosting.hu (server.t-hosting.hu [217.20.133.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id D302F43D99; Sun, 12 Nov 2006 11:07:03 +0000 (GMT) (envelope-from gabor@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by server.t-hosting.hu (Postfix) with ESMTP id 13DB19A1B2C; Sun, 12 Nov 2006 12:07:01 +0100 (CET) X-Virus-Scanned: amavisd-new at t-hosting.hu Received: from server.t-hosting.hu ([127.0.0.1]) by localhost (server.t-hosting.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id UzntJhMFu2fP; Sun, 12 Nov 2006 12:06:55 +0100 (CET) Received: from [192.168.2.186] (catv-50635cb6.catv.broadband.hu [80.99.92.182]) by server.t-hosting.hu (Postfix) with ESMTP id 8B90A9A1B2E; Sun, 12 Nov 2006 12:06:55 +0100 (CET) Message-ID: <4557004A.5070105@FreeBSD.org> Date: Sun, 12 Nov 2006 12:06:50 +0100 From: =?UTF-8?B?R8OhYm9yIEvDtnZlc2TDoW4=?= User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Attilio Rao References: <1162993001.4305.37.camel@massimo.datacode.it> <4553A000.7070407@FreeBSD.org> <1163151468.4328.6.camel@massimo.datacode.it> <200611101459.20117.max@love2party.net> <3bbf2fe10611100747l386a624cpd72d04b62a0681e7@mail.gmail.com> <3bbf2fe10611100751i77e9c8afle0aed1e794062f4f@mail.gmail.com> <3bbf2fe10611101149y72f29285s517f5e40a5b8f3e0@mail.gmail.com> <3bbf2fe10611101157p13296002ic974d45c3fe95e09@mail.gmail.com> In-Reply-To: <3bbf2fe10611101157p13296002ic974d45c3fe95e09@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Max Laier , freebsd-net@freebsd.org, Massimo Lusetti , Florent Thoumie , freebsd-hackers@freebsd.org Subject: Re: New wpi driver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Nov 2006 11:07:17 -0000 Attilio Rao wrote: >> First of all, WPI_PCI_BAR0 might not be defined in this way, but it >> should really use PCIR_BAR() macro. >> Then, probabilly, gabor's device I/O space is relative to another BAR, >> so simply try all 6 using PCIR_BAR(n) where n range is 0-6 until it >> does allocate. > > Sorry, n ranges 0-5... (as I said before 6 different address spaces). > Today it seems I'm absolutely sleeping... (probabilly I'm too angry to > have not parecipied at EuroBSDCon...). > > Attilio > > If I could understand your instructions correctly, I had to change the line sc->mem_rid = WPI_PCI_BAR0 to sc->mem_rid = PCIR_BAR(n) with all the possible n values from 0 to 5. I tried that but it lead nowhere, I still got the same output. If you can ping me on IRC this afternoon, too, I can give you ssh access if you want to take a look. -- Cheers, Gabor From owner-freebsd-net@FreeBSD.ORG Sun Nov 12 16:42:06 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 39EDC16A403; Sun, 12 Nov 2006 16:42:06 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F0DC43D45; Sun, 12 Nov 2006 16:41:54 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id kACGfl9i068088; Sun, 12 Nov 2006 09:41:52 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <45574ECA.4080207@samsco.org> Date: Sun, 12 Nov 2006 09:41:46 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.7) Gecko/20060910 SeaMonkey/1.0.5 MIME-Version: 1.0 To: Mike Tancsa References: <2a41acea0611081719h31be096eu614d2f2325aff511@mail.gmail.com> <200611091536.kA9FaltD018819@lava.sentex.ca> <45534E76.6020906@samsco.org> <200611092200.kA9M0q1E020473@lava.sentex.ca> <200611102004.kAAK4iO9027778@lava.sentex.ca> <2a41acea0611101400w5b8cef40ob84ed6de181f3e2c@mail.gmail.com> <200611102221.kAAML6ol028630@lava.sentex.ca> <455570D8.6070000@samsco.org> <200611120412.kAC4CuIB035746@lava.sentex.ca> In-Reply-To: <200611120412.kAC4CuIB035746@lava.sentex.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: freebsd-net , freebsd-stable@freebsd.org, Jack Vogel Subject: Re: Proposed 6.2 em RELEASE patch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Nov 2006 16:42:06 -0000 Mike Tancsa wrote: > At 01:42 AM 11/11/2006, Scott Long wrote: > driver. What will help me is if you can hook up a serial console to >> your machine and see if it can be made to drop to the debugger while it >> is under load and otherwise unresponsive. If you can, getting a process >> dump might help confirm where each CPU is spending its time. > > > ./netblast 192.168.88.218 500 110 1000 > > I compiled in the various debugging options and on the serial console I > get a few > > Expensive timeout(9) function: 0xc0601e48(0) 0.024135749 s > and the serial console > One CPU seems to be stuck in softclock. My guess here is that there is significant lock contention. Please try the following: 1. Use addr2line or gdb on the kernel to find out what function is at 0xc0601e48 (the address that was printed above). This address will change every time you recompile the kernel, so you'll need to reacquire it from the console each time. 2. Try compiling in WITNESS and running the test as before, then break into the debugger as before. Run 'show locks'. I'm not sure how fruitful this will be, WITNESS might make it unbearably slow. 3. Turn on MUTEX_PROFILING according to the text in /sys/conf/NOTES and the man page by the same name. 4. Remove ADAPTIVE_GIANT from your config and retest. If that doesn't show a difference, then try setting NO_ADAPTIVE_MUTEXES. Thanks, Scott From owner-freebsd-net@FreeBSD.ORG Sun Nov 12 20:26:43 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 A71ED16A47B for ; Sun, 12 Nov 2006 20:26:43 +0000 (UTC) (envelope-from bab@acciodata.com) Received: from smtpout10-04.prod.mesa1.secureserver.net (smtpout10-04.prod.mesa1.secureserver.net [64.202.165.238]) by mx1.FreeBSD.org (Postfix) with SMTP id D0FE443D53 for ; Sun, 12 Nov 2006 20:26:39 +0000 (GMT) (envelope-from bab@acciodata.com) Received: (qmail 7769 invoked from network); 12 Nov 2006 20:26:39 -0000 Received: from unknown (66.68.10.54) by smtpout10-04.prod.mesa1.secureserver.net (64.202.165.238) with ESMTP; 12 Nov 2006 20:26:38 -0000 Received: from bravo.acciodata.com (bab@localhost [127.0.0.1]) by bravo.acciodata.com (8.13.8/8.13.6) with ESMTP id kACKQbUc053646; Sun, 12 Nov 2006 14:26:37 -0600 (CST) (envelope-from bab@bravo.acciodata.com) Received: (from bab@localhost) by bravo.acciodata.com (8.13.6/8.13.4/Submit) id kACKQai4053643; Sun, 12 Nov 2006 14:26:36 -0600 (CST) (envelope-from bab) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17751.33660.897403.267059@gargle.gargle.HOWL> Date: Sun, 12 Nov 2006 14:26:36 -0600 To: "Jack Vogel" In-Reply-To: <2a41acea0611101447j29acdc3k820276de92204735@mail.gmail.com> References: <17748.37662.708865.764722@gargle.gargle.HOWL> <20061110150840.GK32700@cell.sick.ru> <17748.53164.372871.270153@gargle.gargle.HOWL> <17748.64782.579350.492909@gargle.gargle.HOWL> <2a41acea0611101447j29acdc3k820276de92204735@mail.gmail.com> X-Mailer: VM 7.17 under 21.4 (patch 17) "Jumbo Shrimp" XEmacs Lucid From: Barry Boes X-Mailman-Approved-At: Sun, 12 Nov 2006 22:02:27 +0000 Cc: Scott Long , RelEng , John Baldwin , freebsd-net , Barry Boes , jfv@freebsd.org, freebsd-stable@freebsd.org Subject: Re: EM stability X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Barry Boes List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 20:26:43 -0000 After the last hang I added giant locks back in and the machine has been up since. I don't have a serial console, just a graphic console. When the machine hangs it stops replying to ethernet packets at all protocol levels and doesn't respond to keyboard input in any way, virtual console or otherwise. If I run a script of the form while(1) sleep 1 date >> datelog end the file stops updating when the machine hangs. I will define the debugger in the kernel (options DDB, right?), attach a serial console, and do what I can to get more information on the problem. -Barry Jack Vogel writes: > On 11/10/06, Barry Boes wrote: > > > > Luck ran out. Hard "must press the reset button" hang. No console > > messages. The system was idle at the time. > > Is there anything you'd like me to do to attempt to narrow down the > > problem or get debugging output? I do not know if the freeze was > > related to em or something else. > > Is this a machine running some graphic head? If not can you see anything > on the console? Are you sure the machine is dead, like can you get in > over the network... ? One thing I often do when you are dealing with > unpredictable hangs is run 'vmstat 3' on one of the virtual terminals. > > You might also define the kernel debugger into your kernel, its best to have > a serial console for this, I've seen the hardware console be locked but the > serial will still work. > > The only way we will track this down is thru repetitive reproduction I'm > afraid. > > Jack From owner-freebsd-net@FreeBSD.ORG Mon Nov 13 00:40:59 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 3355B16A492; Mon, 13 Nov 2006 00:40:59 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 69EC743D6E; Mon, 13 Nov 2006 00:40:57 +0000 (GMT) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id kAD0euPP019886; Sun, 12 Nov 2006 19:40:56 -0500 (EST) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.6/8.13.3) with ESMTP id kAD0etbp040637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 12 Nov 2006 19:40:55 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <200611130040.kAD0etbp040637@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 12 Nov 2006 19:40:45 -0500 To: Scott Long From: Mike Tancsa In-Reply-To: <45574ECA.4080207@samsco.org> References: <2a41acea0611081719h31be096eu614d2f2325aff511@mail.gmail.com> <200611091536.kA9FaltD018819@lava.sentex.ca> <45534E76.6020906@samsco.org> <200611092200.kA9M0q1E020473@lava.sentex.ca> <200611102004.kAAK4iO9027778@lava.sentex.ca> <2a41acea0611101400w5b8cef40ob84ed6de181f3e2c@mail.gmail.com> <200611102221.kAAML6ol028630@lava.sentex.ca> <455570D8.6070000@samsco.org> <200611120412.kAC4CuIB035746@lava.sentex.ca> <45574ECA.4080207@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: freebsd-net , freebsd-stable@freebsd.org, Jack Vogel Subject: Re: Proposed 6.2 em RELEASE patch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Nov 2006 00:40:59 -0000 At 11:41 AM 11/12/2006, Scott Long wrote: >Mike Tancsa wrote: >>At 01:42 AM 11/11/2006, Scott Long wrote: >>driver. What will help me is if you can hook up a serial console to >>>your machine and see if it can be made to drop to the debugger while it >>>is under load and otherwise unresponsive. If you can, getting a process >>>dump might help confirm where each CPU is spending its time. >> >>./netblast 192.168.88.218 500 110 1000 >>I compiled in the various debugging options and on the serial >>console I get a few >>Expensive timeout(9) function: 0xc0601e48(0) 0.024135749 s >>and the serial console > >One CPU seems to be stuck in softclock. My guess here is that there >is significant lock contention. Please try the following: > >1. Use addr2line or gdb on the kernel to find out what function is at >0xc0601e48 (the address that was printed above). This address will >change every time you recompile the kernel, so you'll need to reacquire >it from the console each time. # addr2line 0xc0601e48 -e kernel.debug -f nfsrv_timer /usr/src/sys/nfsserver/nfs_srvsock.c:809 # and # addr2line 0xc0561444 -e kernel.debug -f sleepq_timeout /usr/src/sys/kern/subr_sleepqueue.c:724 I dont have any nfs activity on the box >2. Try compiling in WITNESS and running the test as before, then break >into the debugger as before. Run 'show locks'. I'm not sure how >fruitful this will be, WITNESS might make it unbearably slow. It was in that kernel already All it would generally show is exclusive spin mutex sio r = 0 (0xc07c81c0) locked @ /usr/src/sys/dev/sio/sio.c:1390 But I did notice in /var/log/kernel Nov 12 00:04:09 R2 kernel: exclusive spin mutex sio r = 0 (0xc07c81c0) locked @ /usr/src/sys/dev/sio/sio.c:1390 Nov 12 00:04:09 R2 kernel: exclusive sleep mutex em1 (network driver) r = 0 (0xc64bc9d4) locked @ /usr/src/sys/dev/ em/if_em.c:3569 Nov 12 00:04:09 R2 kernel: exclusive spin mutex sio r = 0 (0xc07c81c0) locked @ /usr/src/sys/dev/sio/sio.c:1390 Nov 12 19:27:39 R2 kernel: KDB: enter: Line break on console Nov 12 19:27:39 R2 kernel: exclusive spin mutex sio r = 0 (0xc07c81c0) locked @ /usr/src/sys/dev/sio/sio.c:1390 Nov 12 19:28:13 R2 kernel: KDB: enter: Line break on console Nov 12 19:28:13 R2 kernel: exclusive spin mutex sio r = 0 (0xc07c81c0) locked @ /usr/src/sys/dev/sio/sio.c:1390 Nov 12 19:31:37 R2 kernel: KDB: enter: Line break on console Nov 12 19:31:37 R2 kernel: exclusive spin mutex sio r = 0 (0xc07c81c0) locked @ /usr/src/sys/dev/sio/sio.c:1390 Nov 12 19:34:22 R2 kernel: KDB: enter: Line break on console Nov 12 19:34:22 R2 kernel: exclusive spin mutex sio r = 0 (0xc07c81c0) locked @ /usr/src/sys/dev/sio/sio.c:1390 >3. Turn on MUTEX_PROFILING according to the text in /sys/conf/NOTES and >the man page by the same name. >4. Remove ADAPTIVE_GIANT from your config and retest. If that doesn't >show a difference, then try setting NO_ADAPTIVE_MUTEXES. OK, did this recompiling without WITNESS and INVARIANTS and took out ADAPTIVE_GIANT as instructed in the man pages # sysctl -a | grep mutex debug.mutex.prof.enable: 1 debug.mutex.prof.acquisitions: 584672946 debug.mutex.prof.records: 450 debug.mutex.prof.maxrecords: 1000 debug.mutex.prof.rejected: 0 debug.mutex.prof.hashsize: 1009 debug.mutex.prof.collisions: 75 debug.mutex.prof.stats: 10 1263 226 5 0 0 /usr/src/sys/kern/sys_pipe.c:1345 (pipe mutex) 3 682 369 1 13 6908 /usr/src/sys/vm/vm_fault.c:851 (vm page queue mutex) 10 2256 623 3 23 15 /usr/src/sys/i386/i386/pmap.c:1891 (vm page queue mutex) 120 883 401 2 15 26 /usr/src/sys/vm/vm_fault.c:909 (vm page queue mutex) 25 25 1 25 0 0 /usr/src/sys/i386/i386/pmap.c:2572 (vm page queue mutex) 19 169 33 5 1 1 /usr/src/sys/vm/vm_object.c:1801 (vm page queue mutex) 4 24 9 2 0 0 /usr/src/sys/vm/vm_object.c:646 (vm page queue mutex) 3 23 8 2 1 1 /usr/src/sys/kern/vfs_bio.c:3384 (vm page queue mutex) 2 12 6 2 0 0 /usr/src/sys/vm/vm_pageout.c:1511 (vm page queue mutex) 4 120 44 2 0 0 /usr/src/sys/kern/vfs_bio.c:3315 (vm page queue mutex) 3 100 44 2 0 0 /usr/src/sys/kern/vfs_bio.c:3120 (vm page queue mutex) 3 9 4 2 0 0 /usr/src/sys/kern/vfs_bio.c:3577 (vm page queue mutex) 1 1 1 1 0 4 /usr/src/sys/kern/sys_pipe.c:1270 (pipe mutex) 2 16 8 2 0 0 /usr/src/sys/vm/vm_page.c:1481 (vm page queue mutex) 2 8 4 2 0 0 /usr/src/sys/kern/kern_exec.c:871 (vm page queue mutex) 145 713 14 50 5 4 /usr/src/sys/vm/vm_map.c:1504 (vm page queue mutex) 2 7 4 1 0 0 /usr/src/sys/vm/vm_glue.c:273 (vm page queue mutex) 2 8 4 2 0 0 /usr/src/sys/vm/vm_glue.c:309 (vm page queue mutex) 2 8 4 2 0 0 /usr/src/sys/kern/kern_exec.c:893 (vm page queue mutex) 36 357 42 8 2 1 /usr/src/sys/i386/i386/pmap.c:1624 (vm page queue mutex) 5 152 64 2 2 2 /usr/src/sys/vm/vm_fault.c:346 (vm page queue mutex) 2 61 24 2 2 1 /usr/src/sys/vm/vm_fault.c:136 (vm page queue mutex) 5 48 10 4 0 2 /usr/src/sys/i386/i386/pmap.c:1782 (vm page queue mutex) 11 1451 193 7 24 13 /usr/src/sys/vm/vm_fault.c:1009 (vm page queue mutex) 3 3868 1692 2 8 4 /usr/src/sys/kern/sys_pipe.c:993 (pipe mutex) 6 4681 1692 2 46 6 /usr/src/sys/kern/sys_pipe.c:1145 (pipe mutex) 2 643 372 1 0 0 /usr/src/sys/vm/vm_fault.c:1092 (vm page queue mutex) 3 3235 1648 1 5 44 /usr/src/sys/kern/sys_pipe.c:591 (pipe mutex) 5 4235 1647 2 2 2 /usr/src/sys/kern/sys_pipe.c:628 (pipe mutex) 1 331 222 1 0 0 /usr/src/sys/vm/vm_kern.c:367 (vm page queue mutex) 2 337 222 1 0 0 /usr/src/sys/vm/vm_kern.c:404 (vm page queue mutex) debug.mutex.prof.reset: 0 >Thanks, > >Scott From owner-freebsd-net@FreeBSD.ORG Mon Nov 13 01:48:07 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 5EE7416A415; Mon, 13 Nov 2006 01:48:07 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5679543D5E; Mon, 13 Nov 2006 01:48:05 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id kAD1lxBT071427; Sun, 12 Nov 2006 18:48:04 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <4557CECD.2000609@samsco.org> Date: Sun, 12 Nov 2006 18:47:57 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.7) Gecko/20060910 SeaMonkey/1.0.5 MIME-Version: 1.0 To: Mike Tancsa References: <2a41acea0611081719h31be096eu614d2f2325aff511@mail.gmail.com> <200611091536.kA9FaltD018819@lava.sentex.ca> <45534E76.6020906@samsco.org> <200611092200.kA9M0q1E020473@lava.sentex.ca> <200611102004.kAAK4iO9027778@lava.sentex.ca> <2a41acea0611101400w5b8cef40ob84ed6de181f3e2c@mail.gmail.com> <200611102221.kAAML6ol028630@lava.sentex.ca> <455570D8.6070000@samsco.org> <200611120412.kAC4CuIB035746@lava.sentex.ca> <45574ECA.4080207@samsco.org> <200611130040.kAD0etbp040637@lava.sentex.ca> In-Reply-To: <200611130040.kAD0etbp040637@lava.sentex.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: freebsd-net , freebsd-stable@freebsd.org, Jack Vogel Subject: Re: Proposed 6.2 em RELEASE patch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Nov 2006 01:48:07 -0000 Mike Tancsa wrote: > At 11:41 AM 11/12/2006, Scott Long wrote: >> Mike Tancsa wrote: >>> At 01:42 AM 11/11/2006, Scott Long wrote: >>> driver. What will help me is if you can hook up a serial console to >>>> your machine and see if it can be made to drop to the debugger while it >>>> is under load and otherwise unresponsive. If you can, getting a >>>> process >>>> dump might help confirm where each CPU is spending its time. >>> >>> ./netblast 192.168.88.218 500 110 1000 >>> I compiled in the various debugging options and on the serial console >>> I get a few >>> Expensive timeout(9) function: 0xc0601e48(0) 0.024135749 s >>> and the serial console >> >> One CPU seems to be stuck in softclock. My guess here is that there >> is significant lock contention. Please try the following: >> >> 1. Use addr2line or gdb on the kernel to find out what function is at >> 0xc0601e48 (the address that was printed above). This address will >> change every time you recompile the kernel, so you'll need to reacquire >> it from the console each time. > > # addr2line 0xc0601e48 -e kernel.debug -f > nfsrv_timer > /usr/src/sys/nfsserver/nfs_srvsock.c:809 > # > Can you try removing NFS from your kernel? > and > > # addr2line 0xc0561444 -e kernel.debug -f > sleepq_timeout > /usr/src/sys/kern/subr_sleepqueue.c:724 This is sched_lock contention. > > I dont have any nfs activity on the box > >> 2. Try compiling in WITNESS and running the test as before, then break >> into the debugger as before. Run 'show locks'. I'm not sure how >> fruitful this will be, WITNESS might make it unbearably slow. > > It was in that kernel already So you're seeing the livelock under load while also having WITNESS enabled? Have you tried your test without WITNESS? What about INVARIANTS? Scott From owner-freebsd-net@FreeBSD.ORG Mon Nov 13 01:58:41 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 1FF6A16A403; Mon, 13 Nov 2006 01:58:41 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id A3D9E43D5E; Mon, 13 Nov 2006 01:58:40 +0000 (GMT) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id kAD1wdnL060097; Sun, 12 Nov 2006 20:58:40 -0500 (EST) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.6/8.13.3) with ESMTP id kAD1wdKE040908 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 12 Nov 2006 20:58:39 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <200611130158.kAD1wdKE040908@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 12 Nov 2006 20:58:49 -0500 To: Scott Long From: Mike Tancsa In-Reply-To: <4557CECD.2000609@samsco.org> References: <2a41acea0611081719h31be096eu614d2f2325aff511@mail.gmail.com> <200611091536.kA9FaltD018819@lava.sentex.ca> <45534E76.6020906@samsco.org> <200611092200.kA9M0q1E020473@lava.sentex.ca> <200611102004.kAAK4iO9027778@lava.sentex.ca> <2a41acea0611101400w5b8cef40ob84ed6de181f3e2c@mail.gmail.com> <200611102221.kAAML6ol028630@lava.sentex.ca> <455570D8.6070000@samsco.org> <200611120412.kAC4CuIB035746@lava.sentex.ca> <45574ECA.4080207@samsco.org> <200611130040.kAD0etbp040637@lava.sentex.ca> <4557CECD.2000609@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner2 X-Virus-Status: Clean Cc: freebsd-net , freebsd-stable@freebsd.org, Jack Vogel Subject: Re: Proposed 6.2 em RELEASE patch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Nov 2006 01:58:41 -0000 At 08:47 PM 11/12/2006, Scott Long wrote: >>>2. Try compiling in WITNESS and running the test as before, then break >>>into the debugger as before. Run 'show locks'. I'm not sure how >>>fruitful this will be, WITNESS might make it unbearably slow. >>It was in that kernel already > >So you're seeing the livelock under load while also having WITNESS >enabled? Have you tried your test without WITNESS? What about INVARIANTS? Sorry, by it was in the kernel already, it was from last nights tests where you asked me to break into the debugger to see what was going on. I figured you would want it in there. My original tests were all without WITNESS and INVARIANTS and they were showing the same behaviour (locking up on the management interface) with and without WITNESS and INVARIANTS Removing ADAPTIVE_GIANT seems to be very key in this! If I remove it, the box no longer locks up under a high packet rate! Its still a little sluggish on the bge OOB interface, but its not totally locking up like before Running ifstat -b from the management interface, here is the traffic pattern first with one blast running and then the second kicks in. The Kbps/s out on em1 drops in half, but the box is still responsive and bge1... Certainly responsive enough to see the output of ifstat. 218028.4 0.00 0.00 216389.9 0.47 1.17 218971.2 0.00 0.00 217123.1 0.94 2.34 217754.7 0.00 0.00 215677.2 0.94 1.17 215763.1 0.00 0.00 214578.5 0.47 1.17 217850.3 0.00 0.00 216138.7 1.40 2.34 217668.0 0.00 0.00 215888.3 0.47 1.17 em0 em1 bge1 Kbps in Kbps out Kbps in Kbps out Kbps in Kbps out 217382.3 0.00 0.00 216293.8 1.26 1.59 218247.9 118916.5 234167.3 124972.1 0.47 2.17 215973.4 220459.9 393350.0 54875.64 1.40 2.34 217697.7 210984.5 398543.3 58165.20 0.94 3.09 217183.6 200424.9 399096.5 61845.74 0.94 1.17 217788.7 221212.9 400129.8 53716.38 0.47 1.17 217040.0 204934.2 396628.7 61247.34 1.40 2.34 217105.9 201295.5 399274.1 61710.76 0.94 3.09 215605.6 225012.4 397533.5 53237.31 0.94 1.17 217933.3 200346.4 395949.3 62734.52 0.47 1.17 216783.7 205114.1 395923.0 61042.17 0.94 1.17 217885.7 88513.41 159056.4 151418.9 0.47 1.17 216927.2 0.00 0.00 215450.4 0.94 1.17 217454.1 0.00 0.00 215466.6 0.47 1.17 216810.6 0.00 0.00 215564.2 1.40 1.17 217608.3 0.00 0.00 216061.8 0.47 1.17 217452.8 0.00 0.00 215627.1 0.94 1.17 217185.0 0.00 0.00 216079.7 0.47 1.17 However, if I turn on fastforwarding, its back to the old behavior with it locking up. This was with the stock driver. I will try the same test with #define EM_FAST_INTR 1 as well as taking out the nfs option from the kernel driver. Anything else to tune with ? ---Mike >Scott From owner-freebsd-net@FreeBSD.ORG Mon Nov 13 04:05:48 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 45D5216A500; Mon, 13 Nov 2006 04:05:48 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id B36DB43D45; Mon, 13 Nov 2006 04:05:47 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id kAD45eMI072024; Sun, 12 Nov 2006 21:05:46 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <4557EF13.9060305@samsco.org> Date: Sun, 12 Nov 2006 21:05:39 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.7) Gecko/20060910 SeaMonkey/1.0.5 MIME-Version: 1.0 To: Mike Tancsa References: <2a41acea0611081719h31be096eu614d2f2325aff511@mail.gmail.com> <200611091536.kA9FaltD018819@lava.sentex.ca> <45534E76.6020906@samsco.org> <200611092200.kA9M0q1E020473@lava.sentex.ca> <200611102004.kAAK4iO9027778@lava.sentex.ca> <2a41acea0611101400w5b8cef40ob84ed6de181f3e2c@mail.gmail.com> <200611102221.kAAML6ol028630@lava.sentex.ca> <455570D8.6070000@samsco.org> <200611120412.kAC4CuIB035746@lava.sentex.ca> <45574ECA.4080207@samsco.org> <200611130040.kAD0etbp040637@lava.sentex.ca> <4557CECD.2000609@samsco.org> <200611130158.kAD1wdKE040908@lava.sentex.ca> In-Reply-To: <200611130158.kAD1wdKE040908@lava.sentex.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: freebsd-net , freebsd-stable@freebsd.org, Jack Vogel Subject: Re: Proposed 6.2 em RELEASE patch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Nov 2006 04:05:48 -0000 Mike Tancsa wrote: > However, if I turn on fastforwarding, its back to the old behavior with > it locking up. This was with the stock driver. I will try the same test > with > > #define EM_FAST_INTR 1 > > as well as taking out the nfs option from the kernel driver. Anything > else to tune with ? > > ---Mike > Would you mind going so far as to adding NO_ADAPTIVE_MUTEXES? This is excellent data, thanks a lot for working on it. Scott From owner-freebsd-net@FreeBSD.ORG Mon Nov 13 04:53:47 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 261C916A40F; Mon, 13 Nov 2006 04:53:47 +0000 (UTC) (envelope-from josemi@freebsd.jazztel.es) Received: from smtp01.jazztel.es (smtp01.jazztel.es [62.14.3.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C9BB43D49; Mon, 13 Nov 2006 04:53:46 +0000 (GMT) (envelope-from josemi@freebsd.jazztel.es) Received: from [87.217.186.155] (helo=[192.168.254.128]) by smtp01.jazztel.es with esmtpa (Exim 4.60) (envelope-from ) id 1GjTk5-0007Kc-A7; Mon, 13 Nov 2006 05:48:21 +0100 Message-ID: <4557FA58.5060300@freebsd.jazztel.es> Date: Mon, 13 Nov 2006 05:53:44 +0100 From: Jose M Rodriguez User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: multipart/mixed; boundary="------------010004050901090700010503" Cc: obrien@freebsd.org Subject: nfe net driver for nfroce chipsets working on RELENG_6 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Nov 2006 04:53:47 -0000 This is a multi-part message in MIME format. --------------010004050901090700010503 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, I'm using the nfe driver from current in RELENG_6 with a little patch merge from openbsd cvs repo. Workking great on a home network (MCP51). Due the fact that nve seems a dead end, are any plans to MFC the nfe driver soon? patch attached. -- josemi --------------010004050901090700010503 Content-Type: text/plain; name="if_nfe.c.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="if_nfe.c.diff" --- if_nfe.c.orig Sun Nov 12 23:52:01 2006 +++ if_nfe.c Mon Nov 13 05:37:40 2006 @@ -1668,7 +1668,14 @@ bus_dmamap_t map; bus_dma_segment_t segs[NFE_MAX_SCATTER]; int error, i, nsegs; - u_int16_t flags = NFE_TX_VALID; + u_int16_t flags = 0, /* don't activate the first fragment */ + *fflags; /* mark TX_VALID late */ +#if NVLAN > 0 + u_int32_t vtag = 0; + + if (m0->m_flags & M_VLANTAG) + vtag = htole32(NFE_TX_VTAG | m0->m_pkthdr.ether_vtag); +#endif map = sc->txq.data[sc->txq.cur].tx_data_map; @@ -1686,15 +1693,11 @@ return ENOBUFS; } - -#ifdef NFE_CSUM - if (m0->m_pkthdr.csum_flags & CSUM_IP) - flags |= NFE_TX_IP_CSUM; - if (m0->m_pkthdr.csum_flags & CSUM_TCP) - flags |= NFE_TX_TCP_CSUM; - if (m0->m_pkthdr.csum_flags & CSUM_UDP) - flags |= NFE_TX_TCP_CSUM; -#endif + /* Take account of the first fragment */ + if (sc->nfe_flags & NFE_40BIT_ADDR) + fflags = &sc->txq.desc64[sc->txq.cur].flags; + else + fflags = &sc->txq.desc32[sc->txq.cur].flags; for (i = 0; i < nsegs; i++) { data = &sc->txq.data[sc->txq.cur]; @@ -1709,9 +1712,9 @@ desc64->length = htole16(segs[i].ds_len - 1); desc64->flags = htole16(flags); #if NVLAN > 0 - if (m0->m_flags & M_VLANTAG) - desc64->vtag = htole32(NFE_TX_VTAG | - m0->m_pkthdr.ether_vtag); + desc64->vtag = vtag; + /* vtag belong to the first fragment only */ + vtag = 0; #endif } else { desc32 = &sc->txq.desc32[sc->txq.cur]; @@ -1721,26 +1724,34 @@ desc32->flags = htole16(flags); } - /* csum flags and vtag belong to the first fragment only */ - if (nsegs > 1) { - flags &= ~(NFE_TX_IP_CSUM | NFE_TX_TCP_CSUM); - } + /* Next fragments must be valid */ + flags |= NFE_TX_VALID; sc->txq.queued++; sc->txq.cur = (sc->txq.cur + 1) % NFE_TX_RING_COUNT; } /* the whole mbuf chain has been DMA mapped, fix last descriptor */ - if (sc->nfe_flags & NFE_40BIT_ADDR) { - flags |= NFE_TX_LASTFRAG_V2; - desc64->flags = htole16(flags); - } else { - if (sc->nfe_flags & NFE_JUMBO_SUP) - flags |= NFE_TX_LASTFRAG_V2; - else - flags |= NFE_TX_LASTFRAG_V1; - desc32->flags = htole16(flags); - } + if (sc->nfe_flags & NFE_40BIT_ADDR) + desc64->flags |= htole16(NFE_TX_LASTFRAG_V2); + else + desc32->flags |= + htole16((sc->nfe_flags & NFE_JUMBO_SUP)? + NFE_TX_LASTFRAG_V2: + NFE_TX_LASTFRAG_V1); + + /* now do the first fragment with Checksum and TX valid */ + +#ifdef NFE_CSUM + if (m0->m_pkthdr.csum_flags & CSUM_IP) + flags |= NFE_TX_IP_CSUM; + if (m0->m_pkthdr.csum_flags & CSUM_TCP) + flags |= NFE_TX_TCP_CSUM; + if (m0->m_pkthdr.csum_flags & CSUM_UDP) + flags |= NFE_TX_TCP_CSUM; +#endif + + *fflags |= htole16(flags); data->m = m0; data->active = map; --------------010004050901090700010503-- From owner-freebsd-net@FreeBSD.ORG Mon Nov 13 04:54:59 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 976AC16A407; Mon, 13 Nov 2006 04:54:59 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8E50E43D49; Mon, 13 Nov 2006 04:54:41 +0000 (GMT) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id kAD4saZk039190; Sun, 12 Nov 2006 23:54:36 -0500 (EST) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.6/8.13.3) with ESMTP id kAD4sZwe041556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 12 Nov 2006 23:54:35 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <200611130454.kAD4sZwe041556@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 12 Nov 2006 23:54:37 -0500 To: Scott Long From: Mike Tancsa In-Reply-To: <4557EF13.9060305@samsco.org> References: <2a41acea0611081719h31be096eu614d2f2325aff511@mail.gmail.com> <200611091536.kA9FaltD018819@lava.sentex.ca> <45534E76.6020906@samsco.org> <200611092200.kA9M0q1E020473@lava.sentex.ca> <200611102004.kAAK4iO9027778@lava.sentex.ca> <2a41acea0611101400w5b8cef40ob84ed6de181f3e2c@mail.gmail.com> <200611102221.kAAML6ol028630@lava.sentex.ca> <455570D8.6070000@samsco.org> <200611120412.kAC4CuIB035746@lava.sentex.ca> <45574ECA.4080207@samsco.org> <200611130040.kAD0etbp040637@lava.sentex.ca> <4557CECD.2000609@samsco.org> <200611130158.kAD1wdKE040908@lava.sentex.ca> <4557EF13.9060305@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: freebsd-net , freebsd-stable@freebsd.org, Jack Vogel Subject: Re: Proposed 6.2 em RELEASE patch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Nov 2006 04:54:59 -0000 At 11:05 PM 11/12/2006, Scott Long wrote: >Mike Tancsa wrote: >>However, if I turn on fastforwarding, its back to the old behavior >>with it locking up. This was with the stock driver. I will try the >>same test with >>#define EM_FAST_INTR 1 >>as well as taking out the nfs option from the kernel >>driver. Anything else to tune with ? >> ---Mike > >Would you mind going so far as to adding NO_ADAPTIVE_MUTEXES? This is Wow, it totally survives 2 streams (2 in one direction or 2 in opposite directions)... AND it almost can survive a 3rd! It does seem to be dropping packets on em1 when I add in a second stream blasting in the same direction, but its survives. You can see at ** I add in the second stream, and the outbound on em1 drops, even though more packets are going through. I stop the second stream then add a stream going in the other direction. Oddly enough, with a UP kernel it cant do 2 streams, just the one. I thought the extra locking on SMP would make it worse ? In this case it seems no. em0 em1 bge1 Kbps in Kbps out Kbps in Kbps out Kbps in Kbps out 0.00 0.00 0.00 0.00 0.47 1.17 0.00 0.00 0.00 0.00 0.47 1.17 0.00 0.00 0.00 0.00 0.94 1.17 184837.3 0.00 0.00 184634.5 0.47 1.17 416856.2 0.00 0.00 416232.3 0.94 1.17 414080.2 0.00 0.00 413829.7 0.47 1.17 415656.3 0.00 0.00 415449.1 1.40 1.17 413015.0 0.00 0.00 412519.6 0.94 1.17 415094.8 0.00 0.00 414795.6 1.87 1.17 415548.6 0.00 0.00 415323.7 0.47 1.17 416629.6 0.00 0.00 416046.7 1.40 1.17 417032.5 0.00 0.00 416854.1 0.47 1.17 416606.9 0.00 0.00 416217.9 0.94 1.17 591084.4 0.00 0.00 307308.9 0.47 1.17** 692232.6 0.00 0.00 248915.3 1.41 2.34 692837.6 0.00 0.00 248765.0 0.47 1.17 690216.7 0.00 0.00 245400.2 1.26 1.59 697517.9 0.00 0.00 245689.7 0.94 2.34 697039.0 0.00 0.00 245553.8 1.40 3.09 697424.1 0.00 0.00 244360.9 0.47 1.17 692166.5 0.00 0.00 245316.4 0.94 1.17 697102.3 0.00 0.00 244969.0 0.47 1.17 560005.0 0.00 0.00 329704.8 0.94 3.09 405189.2 0.00 0.00 404969.8 0.94 1.17 417511.0 0.00 0.00 416902.5 0.47 1.17 415029.0 0.00 0.00 414745.3 0.94 1.17 411610.7 15798.46 49760.74 347870.8 0.94 1.17 417520.1 55251.77 174393.0 187379.1 1.40 2.34 414477.5 56203.05 174188.7 185302.4 0.47 1.17 em0 em1 bge1 Kbps in Kbps out Kbps in Kbps out Kbps in Kbps out 416985.7 55063.17 174285.5 186733.5 0.94 2.34 415291.6 55358.65 174493.7 184466.1 1.41 5.01 409410.6 57657.47 174494.3 186945.9 0.94 1.17 417197.4 55271.79 173405.6 189667.3 0.94 3.09 415310.8 55503.47 174283.4 186058.0 0.94 1.17 417290.4 55983.99 174279.4 185274.7 0.94 4.59 418032.6 55648.61 174424.4 186057.0 0.94 1.17 416777.8 55283.73 174886.1 185034.6 0.47 1.17 414412.4 33989.34 105397.4 276853.1 0.94 1.17 416477.8 0.00 0.00 415984.6 0.47 1.17 416656.7 0.00 0.00 416117.0 0.94 1.17 416527.4 0.00 0.00 416372.2 0.47 1.17 250260.8 0.00 0.00 250029.2 0.94 1.17 0.00 0.00 0.00 0.00 0.47 1.17 0.00 0.00 0.00 0.00 0.94 1.17 From owner-freebsd-net@FreeBSD.ORG Mon Nov 13 05:15:49 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 E7F3116A4C9; Mon, 13 Nov 2006 05:15:49 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 477C043D58; Mon, 13 Nov 2006 05:15:48 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id kAD5Feaj072384; Sun, 12 Nov 2006 22:15:47 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <4557FF7A.8020704@samsco.org> Date: Sun, 12 Nov 2006 22:15:38 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.7) Gecko/20060910 SeaMonkey/1.0.5 MIME-Version: 1.0 To: Mike Tancsa References: <2a41acea0611081719h31be096eu614d2f2325aff511@mail.gmail.com> <200611091536.kA9FaltD018819@lava.sentex.ca> <45534E76.6020906@samsco.org> <200611092200.kA9M0q1E020473@lava.sentex.ca> <200611102004.kAAK4iO9027778@lava.sentex.ca> <2a41acea0611101400w5b8cef40ob84ed6de181f3e2c@mail.gmail.com> <200611102221.kAAML6ol028630@lava.sentex.ca> <455570D8.6070000@samsco.org> <200611120412.kAC4CuIB035746@lava.sentex.ca> <45574ECA.4080207@samsco.org> <200611130040.kAD0etbp040637@lava.sentex.ca> <4557CECD.2000609@samsco.org> <200611130158.kAD1wdKE040908@lava.sentex.ca> <4557EF13.9060305@samsco.org> <200611130454.kAD4sZwe041556@lava.sentex.ca> In-Reply-To: <200611130454.kAD4sZwe041556@lava.sentex.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: freebsd-net , freebsd-stable@freebsd.org, Jack Vogel Subject: Re: Proposed 6.2 em RELEASE patch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Nov 2006 05:15:50 -0000 Mike Tancsa wrote: > At 11:05 PM 11/12/2006, Scott Long wrote: >> Mike Tancsa wrote: >>> However, if I turn on fastforwarding, its back to the old behavior >>> with it locking up. This was with the stock driver. I will try the >>> same test with >>> #define EM_FAST_INTR 1 >>> as well as taking out the nfs option from the kernel driver. >>> Anything else to tune with ? >>> ---Mike >> >> Would you mind going so far as to adding NO_ADAPTIVE_MUTEXES? This is > > Wow, it totally survives 2 streams (2 in one direction or 2 in opposite > directions)... AND it almost can survive a 3rd! It does seem to be > dropping packets on em1 when I add in a second stream blasting in the > same direction, but its survives. You can see at ** I add in the second > stream, and the outbound on em1 drops, even though more packets are > going through. I stop the second stream then add a stream going in the > other direction. Oddly enough, with a UP kernel it cant do 2 streams, > just the one. I thought the extra locking on SMP would make it worse ? > In this case it seems no. > Is this with EM_INTR_FAST enabled also? Scott From owner-freebsd-net@FreeBSD.ORG Mon Nov 13 11:08:28 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.org 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 BA89116A5AA for ; Mon, 13 Nov 2006 11:08:28 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 866FF43D4C for ; Mon, 13 Nov 2006 11:08:28 +0000 (GMT) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id kADB8SI6091506 for ; Mon, 13 Nov 2006 11:08:28 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id kADB8RWp091502 for freebsd-net@FreeBSD.org; Mon, 13 Nov 2006 11:08:27 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 13 Nov 2006 11:08:27 GMT Message-Id: <200611131108.kADB8RWp091502@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: linimon set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Nov 2006 11:08:28 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- a kern/38554 net changing interface ipaddress doesn't seem to work s kern/39937 net ipstealth issue o kern/92552 net A serious bug in most network drivers from 5.X to 6.X f kern/93220 net [inet6] nd6_lookup: failed to add route for a neighbor s kern/95665 net [if_tun] "ping: sendto: No buffer space available" wit 5 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- s kern/19875 net A new protocol family, PF_IPOPTION, to handle IP optio o conf/23063 net [PATCH] for static ARP tables in rc.network s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s kern/60293 net FreeBSD arp poison patch o kern/95267 net packet drops periodically appear f kern/95277 net [netinet] IP Encapsulation mask_match() returns wrong o kern/102035 net [plip] plip networking disables parallel port printing o conf/102502 net [patch] ifconfig name does't rename netgraph node in n 9 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Nov 13 11:49:10 2006 Return-Path: X-Original-To: net@freebsd.org 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 47A4F16A494 for ; Mon, 13 Nov 2006 11:49:10 +0000 (UTC) (envelope-from k-gleb@yandex.ru) Received: from smtp1.yandex.ru (smtp1.yandex.ru [213.180.223.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id D742143D5E for ; Mon, 13 Nov 2006 11:49:08 +0000 (GMT) (envelope-from k-gleb@yandex.ru) Received: from [194.226.125.34] ([194.226.125.34]:53889 "EHLO h1.d" smtp-auth: "k-gleb" TLS-CIPHER: TLS-PEER-CN1: ) by mail.yandex.ru with ESMTP id S2080037AbWKMLtG (ORCPT ); Mon, 13 Nov 2006 14:49:06 +0300 X-Comment: RFC 2476 MSA function at smtp1.yandex.ru logged sender identity as: k-gleb Received: by h1.d (Postfix, from userid 1000) id CCC5C3579; Mon, 13 Nov 2006 13:47:31 +0200 (EET) Date: Mon, 13 Nov 2006 13:47:31 +0200 From: Gleb Kurtsou To: Andrew Thompson , net@freebsd.org Message-ID: <20061113114731.GA1620@h1.d> References: <200611090632.kA96Wd5Q098835@repoman.freebsd.org> <20061109200037.GA1398@h1.d> <20061109203858.GB60329@heff.fud.org.nz> <20061110200328.GA6904@h1.d> <20061110232108.GA65230@heff.fud.org.nz> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="0OAP2g/MAC+5xKAE" Content-Disposition: inline In-Reply-To: <20061110232108.GA65230@heff.fud.org.nz> User-Agent: Mutt/1.5.11 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: macfw -- layer2 firewall X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Nov 2006 11:49:10 -0000 --0OAP2g/MAC+5xKAE Content-Type: text/plain; charset=koi8-r Content-Disposition: inline On (11/11/2006 12:21), Andrew Thompson wrote: > On Fri, Nov 10, 2006 at 10:03:28PM +0200, Gleb Kurtsou wrote: > > On (10/11/2006 09:38), Andrew Thompson wrote: > > > On Thu, Nov 09, 2006 at 10:00:37PM +0200, Gleb Kurtsou wrote: > > > > On (09/11/2006 06:32), Andrew Thompson wrote: > > > > > thompsa 2006-11-09 06:32:39 UTC > > > > > > > > > > FreeBSD src repository > > > > > > > > > > Modified files: > > > > > sbin/ifconfig ifbridge.c ifconfig.8 > > > > > sys/net if_bridge.c if_bridgevar.h > > > > > Log: > > > > > Add a new address cache type called sticky. On an interface marked sticky any > > > > > address learned by the bridge is made permanent, the address will not age out > > > > > and most importantly will not migrate to another interface. > > > > > > > > > > This can be used to stop mac address poisoning or clients roaming in much the > > > > > same way as static entries without the hassle of preloading the table. > > > > > > > > I have some sort of MAC firewall. It's tested and seems to work reliably > > > > but it's mostly a hack. It adds mtag with source MAC to mbufs and filters > > > > according them. If you you are interesting in reviewing and possibly > > > > committing it, I'll be glad to send you sources. > > > > > > Sure, send me the sources and I will have a look. > > > > Didn't test it on -CURRENT. > > > > It looks like a good piece of work. You should post it to the net@ > mailing list for comments, there has been some discussion lately about > layer2 firewalls. I will try it out as time permits. > > > cheers, > Andrew > In case somebody is interested.. --0OAP2g/MAC+5xKAE-- From owner-freebsd-net@FreeBSD.ORG Mon Nov 13 12:22:31 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.org 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 3E98D16A412; Mon, 13 Nov 2006 12:22:31 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 679C443D49; Mon, 13 Nov 2006 12:22:30 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.4/8.13.3) with ESMTP id kADCME0S068075 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Nov 2006 15:22:14 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.4/8.13.1/Submit) id kADCMDLC068074; Mon, 13 Nov 2006 15:22:13 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Mon, 13 Nov 2006 15:22:13 +0300 From: Gleb Smirnoff To: Barry Boes Message-ID: <20061113122212.GN32700@cell.sick.ru> Mail-Followup-To: Gleb Smirnoff , Barry Boes , Jack Vogel , jfv@freebsd.org, Scott Long , John Baldwin , RelEng , Prafulla Deuskar , freebsd-stable@freebsd.org, freebsd-net References: <17748.37662.708865.764722@gargle.gargle.HOWL> <20061110150840.GK32700@cell.sick.ru> <17748.53164.372871.270153@gargle.gargle.HOWL> <17748.64782.579350.492909@gargle.gargle.HOWL> <2a41acea0611101447j29acdc3k820276de92204735@mail.gmail.com> <17751.33660.897403.267059@gargle.gargle.HOWL> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <17751.33660.897403.267059@gargle.gargle.HOWL> User-Agent: Mutt/1.5.6i Cc: Scott Long , RelEng , John Baldwin , freebsd-net , Prafulla Deuskar , Jack Vogel , jfv@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: EM stability X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Nov 2006 12:22:31 -0000 On Sun, Nov 12, 2006 at 02:26:36PM -0600, Barry Boes wrote: B> After the last hang I added giant locks back in and the machine has B> been up since. B> B> I don't have a serial console, just a graphic console. When the B> machine hangs it stops replying to ethernet packets at all protocol B> levels and doesn't respond to keyboard input in any way, virtual B> console or otherwise. If I run a script of the form B> while(1) B> sleep 1 B> date >> datelog B> end B> B> the file stops updating when the machine hangs. B> B> I will define the debugger in the kernel (options DDB, right?), attach B> a serial console, and do what I can to get more information on the B> problem. Yes, this looks like something is running in an endless loop. Once you compile kernel with debugger, you should enter in several times and see the backtraces. Usually, they will be inside this cycle. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Mon Nov 13 12:48:48 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 9984A16A4AB; Mon, 13 Nov 2006 12:48:48 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id DA31B43D58; Mon, 13 Nov 2006 12:48:47 +0000 (GMT) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id kADCmkaA003746; Mon, 13 Nov 2006 07:48:46 -0500 (EST) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.6/8.13.3) with ESMTP id kADCmieP043730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Nov 2006 07:48:45 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <200611131248.kADCmieP043730@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 13 Nov 2006 07:48:56 -0500 To: Scott Long From: Mike Tancsa In-Reply-To: <4557FF7A.8020704@samsco.org> References: <2a41acea0611081719h31be096eu614d2f2325aff511@mail.gmail.com> <200611091536.kA9FaltD018819@lava.sentex.ca> <45534E76.6020906@samsco.org> <200611092200.kA9M0q1E020473@lava.sentex.ca> <200611102004.kAAK4iO9027778@lava.sentex.ca> <2a41acea0611101400w5b8cef40ob84ed6de181f3e2c@mail.gmail.com> <200611102221.kAAML6ol028630@lava.sentex.ca> <455570D8.6070000@samsco.org> <200611120412.kAC4CuIB035746@lava.sentex.ca> <45574ECA.4080207@samsco.org> <200611130040.kAD0etbp040637@lava.sentex.ca> <4557CECD.2000609@samsco.org> <200611130158.kAD1wdKE040908@lava.sentex.ca> <4557EF13.9060305@samsco.org> <200611130454.kAD4sZwe041556@lava.sentex.ca> <4557FF7A.8020704@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner3 X-Virus-Status: Clean Cc: freebsd-net , freebsd-stable@freebsd.org, Jack Vogel Subject: Re: Proposed 6.2 em RELEASE patch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Nov 2006 12:48:48 -0000 At 12:15 AM 11/13/2006, Scott Long wrote: >Is this with EM_INTR_FAST enabled also? Yes. Havent done the stock case yet, but will do so later today. ---Mike From owner-freebsd-net@FreeBSD.ORG Mon Nov 13 16:53:47 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 885B616A636; Mon, 13 Nov 2006 16:53:47 +0000 (UTC) (envelope-from randy@psg.com) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id E9E5743D9D; Mon, 13 Nov 2006 16:53:44 +0000 (GMT) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by rip.psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1Gjf44-0002eC-2Q; Mon, 13 Nov 2006 16:53:44 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by roam.psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1Gjf2L-0001f7-JO; Mon, 13 Nov 2006 06:51:57 -1000 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17752.41644.706579.902238@roam.psg.com> Date: Mon, 13 Nov 2006 06:51:56 -1000 To: FreeBSD Current Cc: freebsd-net@freebsd.org Subject: fxp going quiescent in current X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Nov 2006 16:53:47 -0000 FreeBSD rip.psg.com 7.0-CURRENT FreeBSD 7.0-CURRENT #3: Sat Nov 11 19:18:23 GMT 2006 root@rip.psg.com:/usr/obj/usr/src/sys/RIP i386 and for the last four or five days, fxp0 goes dead. it shows up and active, but no packets move. down/up does not help. only way out has been reboot. suggestions on how to debug? randy From owner-freebsd-net@FreeBSD.ORG Mon Nov 13 17:20:43 2006 Return-Path: X-Original-To: net@freebsd.org 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 E61D916A47E for ; Mon, 13 Nov 2006 17:20:43 +0000 (UTC) (envelope-from dionch@freemail.gr) Received: from smtp.freemail.gr (smtp.freemail.gr [81.171.104.107]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2526C43E74 for ; Mon, 13 Nov 2006 17:16:21 +0000 (GMT) (envelope-from dionch@freemail.gr) Received: from CDION (ppp232-071.dsl.hol.gr [89.210.232.71]) by smtp.freemail.gr (Postfix) with ESMTP id 5D2AAA08402; Mon, 13 Nov 2006 19:16:11 +0200 (EET) Date: Mon, 13 Nov 2006 19:16:50 +0200 From: Chris Dionissopoulos X-Mailer: The Bat! (v3.80.06) Professional X-Priority: 3 (Normal) Message-ID: <1039986302.20061113191650@freemail.gr> To: Gleb Kurtsou In-Reply-To: <20061113114731.GA1620@h1.d> References: <200611090632.kA96Wd5Q098835@repoman.freebsd.org> <20061109200037.GA1398@h1.d> <20061109203858.GB60329@heff.fud.org.nz> <20061110200328.GA6904@h1.d> <20061110232108.GA65230@heff.fud.org.nz> <20061113114731.GA1620@h1.d> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: macfw -- layer2 firewall X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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: Mon, 13 Nov 2006 17:20:44 -0000 Hello Gleb, Monday, November 13, 2006, 1:47:31 PM, you wrote: > On (11/11/2006 12:21), Andrew Thompson wrote: >> On Fri, Nov 10, 2006 at 10:03:28PM +0200, Gleb Kurtsou wrote: >> > On (10/11/2006 09:38), Andrew Thompson wrote: >> > > On Thu, Nov 09, 2006 at 10:00:37PM +0200, Gleb Kurtsou wrote: >> > > > On (09/11/2006 06:32), Andrew Thompson wrote: >> > > > > thompsa 2006-11-09 06:32:39 UTC >> > > > > >> > > > > FreeBSD src repository >> > > > > >> > > > > Modified files: >> > > > > sbin/ifconfig ifbridge.c ifconfig.8 >> > > > > sys/net if_bridge.c if_bridgevar.h >> > > > > Log: >> > > > > Add a new address cache type called sticky. On an interface marked sticky any >> > > > > address learned by the bridge is made permanent, the address will not age out >> > > > > and most importantly will not migrate to another interface. >> > > > > >> > > > > This can be used to stop mac address poisoning or clients roaming in much the >> > > > > same way as static entries without the hassle of preloading the table. >> > > > >> > > > I have some sort of MAC firewall. It's tested and seems to work reliably >> > > > but it's mostly a hack. It adds mtag with source MAC to mbufs and filters >> > > > according them. If you you are interesting in reviewing and possibly >> > > > committing it, I'll be glad to send you sources. >> > > >> > > Sure, send me the sources and I will have a look. >> > >> > Didn't test it on -CURRENT. >> > >> >> It looks like a good piece of work. You should post it to the net@ >> mailing list for comments, there has been some discussion lately about >> layer2 firewalls. I will try it out as time permits. >> >> >> cheers, >> Andrew >> > In case somebody is interested.. I'm really interest to test your patch. -- Best regards, Chris mailto:dionch@freemail.gr From owner-freebsd-net@FreeBSD.ORG Mon Nov 13 18:01:23 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 7D54F16A4D0 for ; Mon, 13 Nov 2006 18:01:23 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 52F2243DDB for ; Mon, 13 Nov 2006 18:00:45 +0000 (GMT) (envelope-from freebsd-net@m.gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1Gjg6E-0001hr-5N for freebsd-net@freebsd.org; Mon, 13 Nov 2006 19:00:02 +0100 Received: from 83-131-168-146.adsl.net.t-com.hr ([83.131.168.146]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 13 Nov 2006 19:00:02 +0100 Received: from ivoras by 83-131-168-146.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 13 Nov 2006 19:00:02 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Ivan Voras Date: Mon, 13 Nov 2006 18:50:28 +0100 Lines: 8 Message-ID: References: <2a41acea0611081719h31be096eu614d2f2325aff511@mail.gmail.com> <200611091536.kA9FaltD018819@lava.sentex.ca> <45534E76.6020906@samsco.org> <200611092200.kA9M0q1E020473@lava.sentex.ca> <200611102004.kAAK4iO9027778@lava.sentex.ca> <2a41acea0611101400w5b8cef40ob84ed6de181f3e2c@mail.gmail.com> <200611102221.kAAML6ol028630@lava.sentex.ca> <455570D8.6070000@samsco.org> <200611120412.kAC4CuIB035746@lava.sentex.ca> <45574ECA.4080207@samsco.org> <200611130040.kAD0etbp040637@lava.sentex.ca> <4557CECD.2000609@samsco.org> <200611130158.kAD1wdKE040908@lava.sentex.ca> <4557EF13.9060305@samsco.org> <200611130454.kAD4sZwe041556@lava.sentex.ca> <4557FF7A.8020704@samsco.org> <200611131248.kADCmieP043730@lava.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 83-131-168-146.adsl.net.t-com.hr User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) In-Reply-To: <200611131248.kADCmieP043730@lava.sentex.ca> Sender: news Cc: freebsd-stable@freebsd.org Subject: Re: Proposed 6.2 em RELEASE patch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Nov 2006 18:01:23 -0000 Mike Tancsa wrote: > At 12:15 AM 11/13/2006, Scott Long wrote: > >> Is this with EM_INTR_FAST enabled also? > > Yes. Havent done the stock case yet, but will do so later today. Do you have a comparison with Linux under the same circumstances? From owner-freebsd-net@FreeBSD.ORG Mon Nov 13 20:55:28 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 1D28C16A532; Mon, 13 Nov 2006 20:55:28 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3ABDB43DA5; Mon, 13 Nov 2006 20:54:18 +0000 (GMT) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id kADKsGLe014903; Mon, 13 Nov 2006 15:54:16 -0500 (EST) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.6/8.13.3) with ESMTP id kADKsFvK045726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Nov 2006 15:54:15 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <200611132054.kADKsFvK045726@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 13 Nov 2006 15:54:27 -0500 To: Scott Long From: Mike Tancsa In-Reply-To: <4557FF7A.8020704@samsco.org> References: <2a41acea0611081719h31be096eu614d2f2325aff511@mail.gmail.com> <200611091536.kA9FaltD018819@lava.sentex.ca> <45534E76.6020906@samsco.org> <200611092200.kA9M0q1E020473@lava.sentex.ca> <200611102004.kAAK4iO9027778@lava.sentex.ca> <2a41acea0611101400w5b8cef40ob84ed6de181f3e2c@mail.gmail.com> <200611102221.kAAML6ol028630@lava.sentex.ca> <455570D8.6070000@samsco.org> <200611120412.kAC4CuIB035746@lava.sentex.ca> <45574ECA.4080207@samsco.org> <200611130040.kAD0etbp040637@lava.sentex.ca> <4557CECD.2000609@samsco.org> <200611130158.kAD1wdKE040908@lava.sentex.ca> <4557EF13.9060305@samsco.org> <200611130454.kAD4sZwe041556@lava.sentex.ca> <4557FF7A.8020704@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner2 X-Virus-Status: Clean Cc: freebsd-net , freebsd-stable@freebsd.org, Jack Vogel Subject: Re: Proposed 6.2 em RELEASE patch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Nov 2006 20:55:28 -0000 At 12:15 AM 11/13/2006, Scott Long wrote: >Is this with EM_INTR_FAST enabled also? Without it, the 2 streams are definitely lossy on the management interface ---Mike From owner-freebsd-net@FreeBSD.ORG Mon Nov 13 21:39:11 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 9BE1716A515; Mon, 13 Nov 2006 21:39:11 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id EEEA943E81; Mon, 13 Nov 2006 21:30:47 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [10.10.3.185] ([165.236.175.187]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id kADLUBlc085111; Mon, 13 Nov 2006 14:30:16 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <4558E3DC.6080800@samsco.org> Date: Mon, 13 Nov 2006 14:30:04 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060206 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mike Tancsa References: <2a41acea0611081719h31be096eu614d2f2325aff511@mail.gmail.com> <200611091536.kA9FaltD018819@lava.sentex.ca> <45534E76.6020906@samsco.org> <200611092200.kA9M0q1E020473@lava.sentex.ca> <200611102004.kAAK4iO9027778@lava.sentex.ca> <2a41acea0611101400w5b8cef40ob84ed6de181f3e2c@mail.gmail.com> <200611102221.kAAML6ol028630@lava.sentex.ca> <455570D8.6070000@samsco.org> <200611120412.kAC4CuIB035746@lava.sentex.ca> <45574ECA.4080207@samsco.org> <200611130040.kAD0etbp040637@lava.sentex.ca> <4557CECD.2000609@samsco.org> <200611130158.kAD1wdKE040908@lava.sentex.ca> <4557EF13.9060305@samsco.org> <200611130454.kAD4sZwe041556@lava.sentex.ca> <4557FF7A.8020704@samsco.org> <200611132054.kADKsFvK045726@lava.sentex.ca> In-Reply-To: <200611132054.kADKsFvK045726@lava.sentex.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=3.8 tests=none autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: freebsd-net , freebsd-stable@freebsd.org, Jack Vogel Subject: Re: Proposed 6.2 em RELEASE patch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Nov 2006 21:39:11 -0000 Mike Tancsa wrote: > At 12:15 AM 11/13/2006, Scott Long wrote: > > >> Is this with EM_INTR_FAST enabled also? > > > Without it, the 2 streams are definitely lossy on the management interface > > > ---Mike > > Ok, and would you be able to test the polling options as well? Scott From owner-freebsd-net@FreeBSD.ORG Mon Nov 13 21:47:17 2006 Return-Path: X-Original-To: net@freebsd.org 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 2E97F16A4EF for ; Mon, 13 Nov 2006 21:47:17 +0000 (UTC) (envelope-from k-gleb@yandex.ru) Received: from mx18.yandex.ru (smtp2.yandex.ru [213.180.200.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id DCF1F43DCD for ; Mon, 13 Nov 2006 21:44:55 +0000 (GMT) (envelope-from k-gleb@yandex.ru) Received: from [194.226.125.34] ([194.226.125.34]:40590 "EHLO h1.d" smtp-auth: "k-gleb" TLS-CIPHER: TLS-PEER-CN1: ) by mail.yandex.ru with ESMTP id S3375694AbWKMVom (ORCPT ); Tue, 14 Nov 2006 00:44:42 +0300 X-Comment: RFC 2476 MSA function at smtp2.yandex.ru logged sender identity as: k-gleb Received: by h1.d (Postfix, from userid 1000) id CAC203579; Mon, 13 Nov 2006 23:43:09 +0200 (EET) Date: Mon, 13 Nov 2006 23:43:09 +0200 From: Gleb Kurtsou To: Chris Dionissopoulos Message-ID: <20061113214309.GA1366@h1.d> References: <200611090632.kA96Wd5Q098835@repoman.freebsd.org> <20061109200037.GA1398@h1.d> <20061109203858.GB60329@heff.fud.org.nz> <20061110200328.GA6904@h1.d> <20061110232108.GA65230@heff.fud.org.nz> <20061113114731.GA1620@h1.d> <1039986302.20061113191650@freemail.gr> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="BXVAT5kNtrzKuDFl" Content-Disposition: inline In-Reply-To: <1039986302.20061113191650@freemail.gr> User-Agent: Mutt/1.5.11 Cc: net@freebsd.org Subject: Re: macfw -- layer2 firewall X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Nov 2006 21:47:17 -0000 --BXVAT5kNtrzKuDFl Content-Type: text/plain; charset=koi8-r Content-Disposition: inline On (13/11/2006 19:16), Chris Dionissopoulos wrote: [...] > > In case somebody is interested.. > > I'm really interest to test your patch. It looks like attachment was striped. Resending it. --BXVAT5kNtrzKuDFl Content-Type: text/plain; charset=koi8-r Content-Disposition: attachment; filename="macfw.shar.txt" # This is a shell archive. Save it in a file, remove anything before # this line, and then unpack it by entering "sh file". Note, it may # create directories; files and directories will be owned by you and # have default permissions. # # This archive contains: # # macfw # macfw/etc # macfw/etc/rc.fw.mac # macfw/etc/rc.d # macfw/etc/rc.d/macfw.sh # macfw/etc/rc.fw.mac-admin # macfw/etc/rc.conf # macfw/macfwctl # macfw/macfwctl/macfwctl.c # macfw/macfwctl/Makefile # macfw/module # macfw/module/Makefile # macfw/module/macfw.c # macfw/module/macfwvar.h # macfw/module/patch-sys-macfw # echo c - macfw mkdir -p macfw > /dev/null 2>&1 echo c - macfw/etc mkdir -p macfw/etc > /dev/null 2>&1 echo x - macfw/etc/rc.fw.mac sed 's/^X//' >macfw/etc/rc.fw.mac << 'END-of-macfw/etc/rc.fw.mac' X192.168.77.38 00:D0:59:12:F4:F9 X192.168.77.40 00:A0:D2:10:3D:EF X192.168.77.14 00:0A:E6:30:CF:5D X192.168.77.15 4C:00:10:53:73:76 X192.168.77.9 00:04:61:6C:AB:C7 X192.168.77.47 00:0A:E6:77:06:FA X192.168.77.90 00:02:A5:14:81:4C X192.168.78.142 00:50:22:B0:8E:05 X192.168.77.49 4C:00:10:27:0E:F5 X192.168.77.41 00:AA:00:AD:04:15 X192.168.77.11 00:50:22:49:11:19 X192.168.77.151 00:04:61:5E:71:27 X192.168.77.165 00:04:61:4C:33:F5 X192.168.77.12 00:50:22:B0:9C:82 X192.168.77.18 00:04:61:52:0F:4E X192.168.77.19 00:00:10:00:04:E8 X192.168.77.7 00:04:61:77:D9:3B X192.168.77.16 00:04:61:43:AF:29 X192.168.77.21 00:10:B5:41:7C:FF X192.168.77.13 00:04:75:E0:B4:61 X192.168.77.24 00:40:F4:7F:A1:3E X192.168.77.152 00:04:4B:80:80:07 X192.168.77.156 00:13:8F:27:11:A3 X192.168.77.159 00:04:61:7B:38:6B X192.168.77.181 00:0A:E6:7C:2D:37 X192.168.77.177 00:04:61:73:2D:75 X192.168.77.171 00:C0:DF:0F:DF:98 X192.168.77.157 00:0D:87:5F:42:E5 X192.168.77.155 00:E0:4C:77:60:95 X192.168.77.163 00:E0:4C:60:00:23 X192.168.77.162 00:14:78:02:C0:FC X192.168.77.175 00:0A:E6:AD:FD:FB X192.168.77.25 00:04:61:65:08:13 X192.168.77.29 00:0A:E6:30:D8:EE X192.168.77.31 4C:00:10:54:AF:52 X192.168.77.37 00:04:61:93:D2:04 X192.168.77.99 C0:01:DE:AD:BA:BE X192.168.77.50 00:C0:DF:10:BF:A8 X192.168.78.133 00:0C:F1:7D:F2:AD X192.168.78.134 00:60:98:EF:2F:10 X192.168.78.135 00:80:48:23:2C:2E X192.168.78.140 00:14:85:4B:0A:1B X192.168.78.137 00:0A:48:18:20:4A X192.168.78.148 00:13:8F:61:F1:80 X192.168.78.147 4C:00:10:73:28:E1 X192.168.76.1 00:0F:3D:34:8F:98 X192.168.78.20 00:03:47:B9:A5:B2 X192.168.77.153 00:04:61:4E:91:B0 X192.168.77.160 00:0A:E6:61:56:91 X192.168.77.154 00:02:44:69:88:3C X192.168.77.161 00:50:CF:40:EE:20 X192.168.77.164 00:E0:4C:60:00:8C X192.168.78.8 4C:00:10:73:14:7C X192.168.78.5 00:04:61:12:34:56 X192.168.78.139 4C:00:10:71:25:C1 X192.168.78.11 00:0C:6E:06:57:76 X192.168.78.145 00:50:22:91:CD:CD X192.168.77.34 00:15:F2:1D:2E:44 X192.168.77.43 00:04:61:4F:7E:2A X192.168.78.153 00:50:FC:A1:A8:A2 X192.168.76.101 00:02:44:59:C9:30 X192.168.76.18 4C:00:10:3A:E4:12 X192.168.77.35 00:50:22:C8:93:72 X192.168.78.131 00:E0:4C:15:60:90 X192.168.78.150 00:E0:4C:A8:DC:48 X192.168.78.18 00:04:61:59:7F:74 X192.168.77.26 00:80:AD:79:51:B0 X192.168.77.33 4C:00:10:3A:5C:2F X192.168.77.45 4C:00:10:53:79:9A X192.168.78.151 00:13:8F:51:21:36 X192.168.76.4 00:05:5D:34:2C:D8 X192.168.76.99 00:02:44:75:B1:F1 X192.168.77.39 4C:00:10:00:FF:32 X192.168.76.13 00:17:31:E4:0D:53 X192.168.76.30 00:A0:D2:11:AB:E6 X192.168.79.59 00:13:D4:54:1A:9C X192.168.76.33 00:08:A1:7E:F5:77 X192.168.76.35 00:E0:4C:70:6E:0B X192.168.78.136 00:14:85:0B:6F:6A X192.168.76.117 00:0F:EA:F4:45:54 X192.168.76.103 00:50:22:9B:FA:57 X192.168.77.48 00:E0:4C:21:A2:8F X192.168.76.76 00:02:44:73:7C:C5 X192.168.76.77 00:0F:EA:8A:BB:61 X192.168.76.3 00:02:44:75:B2:00 X192.168.77.190 00:02:44:6F:F4:40 X192.168.77.46 00:0B:6A:77:DB:9C X192.168.76.24 00:05:1C:0F:EF:0A X192.168.78.132 00:04:61:58:50:7E X192.168.76.5 A0:00:8F:E0:1A:1F X192.168.76.6 00:50:22:C8:40:A3 X192.168.77.44 00:0E:A6:C0:57:21 X192.168.77.52 00:04:61:55:F0:8E X192.168.78.12 4C:00:10:A2:5C:4D X192.168.78.141 00:60:98:EF:14:06 X192.168.77.27 00:E0:4C:AA:1B:CB X192.168.77.30 00:0D:9D:5F:8E:04 X192.168.78.15 00:0F:EA:3E:DB:1C X192.168.78.6 00:04:61:98:56:B8 X192.168.76.21 00:C0:F6:B3:89:52 X192.168.76.16 4C:00:10:3B:21:21 X192.168.76.22 00:50:22:BB:28:94 X192.168.76.9 00:11:95:F5:6C:4D X192.168.78.146 4C:00:10:74:E1:F5 X192.168.78.16 4C:00:10:76:0F:54 X192.168.78.13 00:0F:B0:A5:3E:06 X192.168.78.19 4C:00:10:51:10:51 X192.168.78.7 00:0C:F1:B9:72:CE X192.168.78.143 00:0D:61:2E:B6:40 X192.168.78.14 00:04:61:55:9C:96 X192.168.76.14 00:40:F4:86:12:47 X192.168.76.7 00:02:44:34:F2:FA X192.168.76.11 00:02:44:72:5B:C2 X192.168.78.152 4C:00:10:74:E7:32 X192.168.78.9 00:11:D8:A3:61:28 X192.168.76.34 00:04:61:79:EE:A5 X192.168.76.20 4C:00:10:74:A4:4C X192.168.76.23 00:0A:E6:5C:F8:B2 X192.168.76.69 00:10:A4:96:B1:07 X192.168.76.25 00:04:61:79:29:CE X192.168.77.196 00:10:A4:E9:48:40 X192.168.76.32 00:0A:CD:03:A9:13 X192.168.76.10 00:0F:EA:2B:A2:CC X192.168.78.149 4C:00:10:51:19:CF X192.168.77.53 00:04:61:63:CC:DB X192.168.76.39 00:10:5A:BC:29:98 X192.168.79.57 00:14:85:85:69:2D X192.168.76.15 00:02:44:72:5B:85 X192.168.76.36 00:C0:DF:07:F4:70 X192.168.78.21 00:15:F2:20:C3:6E X192.168.79.9 00:03:47:0F:84:65 X192.168.76.37 00:40:F4:B6:12:A5 X192.168.76.38 00:08:A1:7F:0D:3C X192.168.78.22 00:0A:48:17:13:42 X192.168.78.23 00:02:B3:48:C6:E8 X192.168.78.154 00:0A:E6:C7:0B:36 X192.168.77.55 00:02:44:57:00:11 X192.168.77.56 00:04:61:EB:FF:FF X192.168.78.167 00:00:E2:7B:3F:1B X192.168.77.54 00:0F:EA:37:B9:09 X192.168.77.57 00:0B:6A:A9:9C:3E X192.168.78.24 00:0D:88:39:ED:84 X192.168.79.65 00:20:ED:7C:9C:44 X192.168.77.59 00:00:10:00:06:0E X192.168.77.60 4C:00:10:3A:D3:A4 X192.168.78.31 00:04:61:65:C5:2F X192.168.76.75 4C:00:10:74:B4:0D X192.168.79.102 00:E0:4C:77:17:49 X192.168.76.40 00:C0:DF:0D:E2:08 X192.168.79.54 00:C0:26:A6:96:EA X192.168.78.26 00:0D:88:39:EE:20 X192.168.78.27 00:D0:B7:B2:3F:37 X192.168.78.25 00:04:61:53:94:22 X192.168.77.65 00:0F:EA:B6:C2:65 X192.168.79.156 00:11:95:26:F5:5C X192.168.79.157 00:0A:E6:74:91:D9 X192.168.79.153 00:E0:4C:21:A5:62 X192.168.79.56 00:11:95:26:F5:6B X192.168.77.69 00:10:DC:70:D8:9A X192.168.76.41 4C:00:10:3A:D4:29 X192.168.78.156 00:E0:4C:21:A5:4E X192.168.76.46 00:0B:6A:7F:A8:06 X192.168.76.45 00:50:22:B0:92:F8 X192.168.76.42 00:14:78:02:A4:C4 X192.168.79.161 00:60:98:EF:36:18 X192.168.79.162 00:13:8F:7D:29:34 X192.168.77.73 00:04:61:94:3F:FE X192.168.79.160 00:01:6C:E6:86:6F X192.168.78.157 00:E0:4C:21:A6:0D X192.168.76.43 04:68:02:40:02:15 X192.168.79.16 00:04:61:7A:41:93 X192.168.78.158 00:11:95:5C:2A:80 X192.168.79.5 00:04:61:5D:EE:42 X192.168.79.6 00:04:61:68:32:74 X192.168.76.49 00:03:0D:35:35:79 X192.168.76.51 00:04:61:69:71:54 X192.168.79.8 00:E0:4C:15:60:92 X192.168.78.163 00:E0:4C:7D:3D:36 X192.168.78.164 00:00:0E:21:02:C7 X192.168.76.52 00:11:D8:9F:E8:55 X192.168.79.7 00:0A:E4:A9:38:D5 X192.168.76.50 4C:00:10:74:B5:3A X192.168.78.160 00:04:61:77:94:DA X192.168.79.159 00:04:61:52:15:E8 X192.168.79.101 00:02:44:96:A2:D7 X192.168.79.163 4C:00:10:74:99:64 X192.168.76.60 00:0B:6A:AE:8C:AF X192.168.76.61 00:30:18:43:BA:CE X192.168.78.162 00:02:44:83:B5:10 X192.168.77.61 4C:00:10:51:37:46 X192.168.76.64 7A:00:B1:90:57:08 X192.168.77.74 00:0B:6A:7D:48:B7 X192.168.79.61 00:08:02:DE:00:2E X192.168.77.75 00:E0:4C:F0:02:81 X192.168.77.79 00:50:22:93:D7:57 X192.168.77.176 00:C0:DF:03:19:FF X192.168.79.165 00:E0:4C:77:27:45 X192.168.78.44 00:04:61:71:1D:AC X192.168.78.30 00:04:61:43:75:DD X192.168.77.183 00:14:85:86:1B:35 X192.168.77.191 4C:00:10:71:CF:D2 X192.168.78.168 00:01:6C:29:1B:38 X192.168.77.185 4C:00:10:3B:4A:B7 X192.168.78.34 00:14:85:F4:6B:C8 X192.168.77.81 00:0D:87:86:B3:C6 X192.168.77.95 00:C0:9F:91:33:58 X192.168.78.32 00:E0:4C:1A:B8:D7 X192.168.76.62 00:0B:6A:A9:06:5F X192.168.79.51 00:00:10:00:00:00 X192.168.77.188 00:80:48:40:13:EF X192.168.78.178 00:0B:6A:89:09:20 X192.168.77.166 4C:00:10:3B:76:3B X192.168.79.60 00:13:8F:88:A9:F3 X192.168.79.62 00:E0:4C:45:1E:22 X192.168.77.82 00:0A:E6:85:E7:E0 X192.168.76.55 00:04:61:97:C4:DE X192.168.77.83 00:13:8F:BB:F0:51 X192.168.77.84 00:13:D3:5E:FB:83 X192.168.77.192 00:11:2F:D9:81:5B X192.168.79.18 00:E0:4C:D9:CC:D2 X192.168.79.155 00:14:85:4A:38:70 X192.168.79.158 00:E0:4C:77:1B:CA X192.168.78.39 00:0F:EA:A2:31:98 X192.168.78.37 00:11:43:56:50:7F X192.168.77.85 00:04:61:A3:68:0A X192.168.77.193 00:13:8F:26:53:02 X192.168.77.86 00:02:44:AB:DB:51 X192.168.76.17 00:02:44:75:21:3C X192.168.79.103 00:10:4B:57:F0:66 X192.168.77.70 00:C0:DF:03:14:92 X192.168.76.47 00:A1:B0:A2:D0:BE X192.168.77.87 00:02:44:AB:DB:01 X192.168.78.170 00:14:78:02:C0:FE X192.168.79.10 00:04:61:A7:20:90 X192.168.78.171 00:0F:EA:B8:D3:F1 X192.168.78.38 00:14:85:8A:F0:F5 X192.168.78.42 AA:AA:AA:AA:AA:AA X192.168.78.165 00:00:00:00:E2:BB X192.168.77.32 00:0C:6E:01:78:09 X192.168.78.48 00:E0:4C:A4:DF:3C X192.168.79.17 00:15:F2:5C:ED:28 X192.168.77.91 00:04:61:76:AD:69 X192.168.78.172 00:0C:29:7F:AB:54 X192.168.79.152 00:13:8F:71:6E:BF X192.168.79.151 00:0F:B0:93:00:13 X192.168.79.11 00:E0:4C:00:7B:22 X192.168.76.58 00:13:8F:2A:B4:81 X192.168.78.177 00:40:F4:B2:8B:44 X192.168.78.161 00:E0:4C:81:63:55 X192.168.78.174 00:E0:4C:A4:78:68 X192.168.77.62 00:04:61:6D:C6:86 X192.168.77.63 00:0B:6A:C7:43:CD X192.168.78.175 00:13:8F:5E:EC:D7 X192.168.77.76 00:04:4B:80:80:03 X192.168.77.66 00:13:8F:3C:04:7C X192.168.79.12 00:40:F4:CF:BC:18 X192.168.77.42 00:04:61:74:77:BD X192.168.79.13 00:13:8F:6C:9D:A2 X192.168.76.67 00:0F:EA:2C:B1:B8 X192.168.76.44 00:15:60:C6:CE:8D X192.168.79.14 00:E0:4C:A8:BB:06 X192.168.76.59 00:13:46:61:D8:88 X192.168.79.52 00:0C:76:38:0B:3C X192.168.78.43 00:04:61:A8:3A:5F X192.168.78.180 00:30:84:89:09:5B X192.168.77.93 00:E0:4C:AA:E2:FB X192.168.77.71 00:E0:4C:77:17:77 X192.168.76.19 00:E0:4C:60:6D:2A X192.168.78.45 00:D0:59:BF:4A:04 X192.168.78.46 00:04:61:A3:05:C4 X192.168.78.181 00:0A:48:1D:E3:7C X192.168.79.68 00:13:D4:6A:F8:B9 X192.168.76.68 00:D0:59:C1:C9:49 X192.168.76.54 00:11:2F:BD:08:B2 X192.168.78.182 00:FF:34:24:39:35 X192.168.78.183 00:13:8F:51:24:07 X192.168.78.47 4C:00:10:53:5C:61 X192.168.78.184 00:04:61:9F:7C:89 X192.168.79.19 00:E0:4C:EF:28:B3 X192.168.76.70 00:0A:48:0E:56:EF X192.168.78.185 00:04:61:A8:7F:53 X192.168.76.71 00:13:8F:9F:B4:FC X192.168.78.49 00:14:85:51:CD:49 X192.168.76.28 00:10:60:F6:F4:B6 X192.168.77.97 00:17:08:3D:81:8E X192.168.76.72 00:14:85:10:3D:E6 X192.168.79.20 00:13:D3:3A:9B:43 X192.168.79.22 00:14:C2:D7:22:5F X192.168.77.98 00:E0:4C:5A:D6:5B X192.168.77.80 00:E0:4C:69:A0:E5 X192.168.77.170 00:15:E9:3D:3E:68 X192.168.77.178 00:16:36:3C:42:07 X192.168.77.198 00:D0:59:83:A4:13 X192.168.78.186 00:04:61:9F:23:31 X192.168.78.50 00:14:85:85:AE:CC X192.168.76.73 00:0B:6A:E8:39:40 X192.168.79.69 00:13:8F:BC:A4:37 X192.168.79.70 00:40:CA:DE:F3:82 X192.168.78.188 00:16:E6:5C:AD:F8 X192.168.78.187 00:04:61:FF:FF:F1 X192.168.78.51 00:E0:4C:1A:D0:87 X192.168.76.81 00:E0:4C:85:2B:B2 X192.168.78.52 00:50:22:B0:8C:57 X192.168.76.85 00:15:E9:41:A0:8C X192.168.78.53 00:02:44:8C:A4:45 X192.168.78.54 00:13:8F:35:91:35 X192.168.77.200 00:17:31:B6:F1:9C X192.168.78.189 00:D0:59:A1:D5:AF X192.168.77.101 00:01:6C:B8:E6:23 X192.168.78.55 00:08:A1:9F:38:97 X192.168.79.166 00:0E:A6:6D:47:D6 X192.168.79.71 00:C0:9F:C0:EC:F3 X192.168.79.72 00:13:8F:E2:46:38 X192.168.78.190 00:10:A4:C1:BC:11 X192.168.76.86 00:01:6C:F3:6A:BC X192.168.77.202 00:0B:6A:ED:85:01 X192.168.77.203 00:13:8F:44:27:02 X192.168.77.201 00:50:70:C5:4C:C4 X192.168.77.205 00:04:61:6E:60:38 X192.168.78.191 00:01:02:F0:DA:88 X192.168.78.192 00:50:22:83:0C:D6 X192.168.77.204 00:00:00:00:00:00 X192.168.76.74 00:13:8F:C7:A3:B3 END-of-macfw/etc/rc.fw.mac echo c - macfw/etc/rc.d mkdir -p macfw/etc/rc.d > /dev/null 2>&1 echo x - macfw/etc/rc.d/macfw.sh sed 's/^X//' >macfw/etc/rc.d/macfw.sh << 'END-of-macfw/etc/rc.d/macfw.sh' X#!/bin/sh X# X X# PROVIDE: macfw X# REQUIRE: root mountcritlocal netif X# KEYWORD: nojail X X. /etc/rc.subr X Xname="macfw" Xrcvar=`set_rcvar` Xload_rc_config $name Xstart_cmd="macfw_start" Xstop_cmd="macfw_stop" X Xmacfw_start() X{ X echo -n "Enabling macfw: " X /root/bin/macfwctl disable X /root/bin/macfwctl flush X for _f in $macfw_files; do X if [ -f $_f ]; then X echo -n "$_f " X while read _ip _mac; do X if [ -z "$_ip" -o -z "$_mac" ]; then X continue X fi X /root/bin/macfwctl -d add "$_ip" "$_mac" X # || exit 1 X done < $_f X fi X done X /root/bin/macfwctl enable X echo "." X} X Xmacfw_stop() X{ X echo "Disabling macfw." X /root/bin/macfwctl disable X} X Xrun_rc_command "$1" X END-of-macfw/etc/rc.d/macfw.sh echo x - macfw/etc/rc.fw.mac-admin sed 's/^X//' >macfw/etc/rc.fw.mac-admin << 'END-of-macfw/etc/rc.fw.mac-admin' X192.168.77.9 00:04:61:6C:AB:C7 X192.168.77.7 00:04:61:77:D9:3B X192.168.79.60 00:13:8F:88:A9:F3 END-of-macfw/etc/rc.fw.mac-admin echo x - macfw/etc/rc.conf sed 's/^X//' >macfw/etc/rc.conf << 'END-of-macfw/etc/rc.conf' Xmacfw_files="/etc/rc.fw.mac-admin /etc/rc.fw.mac" Xmacfw_enable="YES" END-of-macfw/etc/rc.conf echo c - macfw/macfwctl mkdir -p macfw/macfwctl > /dev/null 2>&1 echo x - macfw/macfwctl/macfwctl.c sed 's/^X//' >macfw/macfwctl/macfwctl.c << 'END-of-macfw/macfwctl/macfwctl.c' X/*- X * Copyright (c) 2006 Gleb Kurtsov X * All rights reserved. X * X * Redistribution and use in source and binary forms, with or without X * modification, are permitted provided that the following conditions X * are met: X * 1. Redistributions of source code must retain the above copyright X * notice, this list of conditions and the following disclaimer. X * 2. Redistributions in binary form must reproduce the above copyright X * notice, this list of conditions and the following disclaimer in the X * documentation and/or other materials provided with the distribution. X * X * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND X * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE X * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE X * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE X * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL X * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS X * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) X * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT X * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY X * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF X * SUCH DAMAGE. X * X */ X X#include X#include X#include X#include X#include X#include X#include X#include X#include X#include X#include X X#include "macfwvar.h" X X#define MACFW_DEV "/dev/macfw" X#define MACFW_SYSCTL "net.inet.macfw" X Xstatic char *argv0; Xstatic int opt_v = 0, opt_d = 0; X Xstatic int ac_stat(int macfw_fd, int argc, char **argv); Xstatic int ac_enable(int macfw_fd, int argc, char **argv); Xstatic int ac_show(int macfw_fd, int argc, char **argv); Xstatic int ac_add(int macfw_fd, int argc, char **argv); Xstatic int ac_flush(int macfw_fd, int argc, char **argv); X Xstruct ac_t { X const char *cmd, *args; X int open_flags; X int (*handler)(int, int, char **); X}; Xstatic const struct ac_t acs[] = { X { .cmd = "stat", .handler = ac_stat, .open_flags = -1 }, X { .cmd = "enable", .handler = ac_enable, .open_flags = -1 }, X { .cmd = "disable", .handler = ac_enable, .open_flags = -1 }, X { .cmd = "show", .handler = ac_show, .open_flags = O_RDONLY }, X { .cmd = "add", .handler = ac_add, .open_flags = O_RDWR, .args = " " }, X { .cmd = "flush", .handler = ac_flush, .open_flags = O_RDWR }, X { .cmd = "zero", .handler = ac_flush, .open_flags = O_RDWR }, X { .cmd = NULL } X}; X Xstatic void usage() X{ X const struct ac_t *ac; X X fprintf(stderr, "usage: %s [-vd] \n" X "where is one of:\n", argv0); X for (ac = &acs[0]; ac->cmd != NULL; ++ac) { X fprintf(stderr, "\t%s %s\n", ac->cmd, (ac->args == NULL ? "" : ac->args)); X } X} X Xstatic int ac_stat(int macfw_fd, int argc, char **argv) X{ X char buf[128]; X struct { X unsigned int val; X const char *name; X const char *descr; X } _stat[] = { X { .name = "enable", .descr = "Enabled" }, X { .name = "stat.pass", .descr = "Packets passed" }, X { .name = "stat.unknown", .descr = "Packets ignored" }, X { .name = "stat.spoof_ip", .descr = "Packets with spoofed IP" }, X { .name = "stat.spoof_mac", .descr = "Packets with spoofed MAC" }, X { .name = NULL } X }, *stat = _stat; X size_t sz; X int s; X X for (; stat[0].name; ++stat) { X snprintf(buf, sizeof(buf), "%s.%s", MACFW_SYSCTL, stat[0].name); X sz = sizeof(stat[0].val); X s = sysctlbyname(buf, &stat[0].val, &sz, NULL, 0); X if (s == -1) { X fprintf(stderr, "sysctl(%s): %s\n", buf, strerror(errno)); X return (2); X } X printf("%s: %u\n", stat[0].descr, stat[0].val); X } X return (0); X} X Xstatic int ac_enable(int macfw_fd, int argc, char **argv) X{ X const char *buf = MACFW_SYSCTL ".enable"; X int val, s; X X val = (argv[0][0] == 'e' ? 1 : 0); X s = sysctlbyname(buf, NULL, NULL, &val, sizeof(val)); X if (s == -1) { X fprintf(stderr, "sysctl(%s): %s\n", buf, strerror(errno)); X return (2); X } X return (0); X} X X Xstatic int ac_show(int macfw_fd, int argc, char **argv) X{ X struct macfwioc_rule mr; X int s; X X bzero(&mr, sizeof(struct macfwioc_rule)); X s = ioctl(macfw_fd, MACFWIOCGETRULE, &mr); X while (s != -1) { X printf("%-16s %-18s%s", X inet_ntoa(mr.mr_in), X ether_ntoa(&mr.mr_ether), X (opt_v ? " " : "\n")); X if (opt_v) X printf("[ Pass: %5u, Spoofed IP: %5u, Spoofed MAC: %5u ]\n", X mr.mr_stat_pass, mr.mr_stat_spoof_ip, mr.mr_stat_spoof_mac); X s = ioctl(macfw_fd, MACFWIOCGETRULE, &mr); X } X if (errno != ENOENT) { X fprintf(stderr, "ioctl(%s, MACFWIOCGETRULE): %s\n", MACFW_DEV, strerror(errno)); X return (3); X } X return (0); X} X Xstatic int ac_add(int macfw_fd, int argc, char **argv) X{ X struct macfwioc_rule mr; X struct ether_addr *ea; X int s; X X argc -= 1; X argv += 1; X X bzero(&mr, sizeof(struct macfwioc_rule)); X if (argc != 2 || (ea = ether_aton(argv[1])) == NULL || X inet_aton(argv[0], &mr.mr_in) == 0) { X fprintf(stderr, "%s: add rule: illegal arguments\n", argv0); X usage(); X return (1); X } X mr.mr_ether = *ea; X s = ioctl(macfw_fd, MACFWIOCADDRULE, &mr); X if (s == -1 && !(opt_d != 0 && errno == EEXIST)) { X fprintf(stderr, "ioctl(%s, MACFWIOCADDRULE): %s, %s: %s\n", X MACFW_DEV, argv[0], argv[1], strerror(errno)); X return (3); X } X return (0); X} X Xstatic int ac_flush(int macfw_fd, int argc, char **argv) X{ X int s; X X s = ioctl(macfw_fd, (argv[0][0] == 'f' ? MACFWIOCFLUSH : MACFWIOCZERO)); X if (s == -1) { X fprintf(stderr, "ioctl(%s, MACFWIOCFLUSH): %s\n", MACFW_DEV, strerror(errno)); X return (3); X } X return (0); X} X Xint main(int argc, char** argv) X{ X int macfw_fd; X const struct ac_t *ac; X X int s; X X argv0 = basename(argv[0]); X X for(s=0; s != '?' && (s = getopt(argc, argv, "vd")) != -1;) { X switch(s) { X case 'v': X opt_v = 1; X break; X case 'd': X opt_d = 1; X break; X default: X s = '?'; X } X } X X if (s == '?') { X usage(); X return (1); X } X argc -= optind; X argv += optind; X X if (argc < 1) { X ac = &acs[0]; X } else { X const struct ac_t *ac_i; X X for (ac = NULL, ac_i = &acs[0]; ac_i->cmd != NULL; ++ac_i) { X if (strcmp(argv[0], ac_i->cmd) == 0) { X ac = ac_i; X break; X } X } X } X if (ac == NULL) { X fprintf(stderr, "%s: illegal command: %s\n", argv0, argv[0]); X usage(); X return (1); X } X X if (ac->open_flags != -1) { X macfw_fd = open(MACFW_DEV, ac->open_flags); X if (macfw_fd == -1) { X fprintf(stderr, "open(%s): %s\n", MACFW_DEV, strerror(errno)); X return (2); X } X } else { X macfw_fd = -1; X } X X s = ac->handler(macfw_fd, argc, argv); X X return (s); X} X END-of-macfw/macfwctl/macfwctl.c echo x - macfw/macfwctl/Makefile sed 's/^X//' >macfw/macfwctl/Makefile << 'END-of-macfw/macfwctl/Makefile' X XPROG= macfwctl X XCFLAGS+= -I../module X X#DEBUG_FLAGS= -O0 -g X XWARNS= 2 XNO_WERROR= yes X X.if !defined(NODEBUG) XDEBUG_FLAGS= -g X.endif X XNO_MAN= yes X X.include END-of-macfw/macfwctl/Makefile echo c - macfw/module mkdir -p macfw/module > /dev/null 2>&1 echo x - macfw/module/Makefile sed 's/^X//' >macfw/module/Makefile << 'END-of-macfw/module/Makefile' X# X XKMOD= macfw XSRCS= macfw.c X X#DEBUG_FLAGS+= -DMACFW_DEBUG X X.include END-of-macfw/module/Makefile echo x - macfw/module/macfw.c sed 's/^X//' >macfw/module/macfw.c << 'END-of-macfw/module/macfw.c' X/*- X * Copyright (c) 2006 Gleb Kurtsov X * All rights reserved. X * X * Redistribution and use in source and binary forms, with or without X * modification, are permitted provided that the following conditions X * are met: X * 1. Redistributions of source code must retain the above copyright X * notice, this list of conditions and the following disclaimer. X * 2. Redistributions in binary form must reproduce the above copyright X * notice, this list of conditions and the following disclaimer in the X * documentation and/or other materials provided with the distribution. X * X * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND X * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE X * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE X * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE X * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL X * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS X * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) X * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT X * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY X * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF X * SUCH DAMAGE. X * X */ X X#include X#include X#include X#include X#include X#include X#include X#include X#include X#include X#include X#include X#include X#include X#include X#include X#include X#include X#include X#include X#include X#include X#include X#include X#include X#include X#include X#include X X#include "macfwvar.h" X X#define MACFW_NAME "macfw" X Xstatic d_ioctl_t macfw_ioctl; X Xstatic struct cdevsw macfw_devsw = { X .d_version = D_VERSION, X .d_ioctl = macfw_ioctl, X .d_name = MACFW_NAME X}; Xstatic int macfw_enable = 0; Xstatic int macfw_log = 0; Xstatic int macfw_pfil_hooked = 0; Xstatic int macfw_ticket = 1; Xstatic struct sx macfw_sxlock; X Xstatic struct cdev *macfw_dev; X Xstatic unsigned int macfw_stat_unknown = 0; X Xstruct macfw_entry { X RB_ENTRY(macfw_entry) macfwe_in_entry; X RB_ENTRY(macfw_entry) macfwe_ether_entry; X struct in_addr macfwe_in; X struct ether_addr macfwe_ether; X unsigned int macfwe_stat_pass; X unsigned int macfwe_stat_spoof_ip; X unsigned int macfwe_stat_spoof_mac; X}; X Xuma_zone_t macfw_entry_zone; X Xstatic int macfwe_in_cmp(struct macfw_entry *, struct macfw_entry *); Xstatic int macfwe_ether_cmp(struct macfw_entry *, struct macfw_entry *); X XRB_HEAD(macfw_in_tree, macfw_entry); XRB_PROTOTYPE(macfw_in_tree, macfw_entry, macfwe_in_entry, macfwe_in_cmp); X XRB_HEAD(macfw_ether_tree, macfw_entry); XRB_PROTOTYPE(macfw_ether_tree, macfw_entry, macfwe_ether_entry, macfwe_ether_cmp); X Xstatic struct macfw_in_tree macfw_in_q; Xstatic struct macfw_ether_tree macfw_ether_q; X XRB_GENERATE(macfw_in_tree, macfw_entry, macfwe_in_entry, macfwe_in_cmp); XRB_GENERATE(macfw_ether_tree, macfw_entry, macfwe_ether_entry, macfwe_ether_cmp); X Xstatic int macfw_sysctl(SYSCTL_HANDLER_ARGS); X XSYSCTL_NODE(_net_inet, OID_AUTO, macfw, CTLFLAG_RW, 0, "macfw"); XSYSCTL_INT(_net_inet_macfw, OID_AUTO, enable, CTLFLAG_RW | CTLFLAG_SECURE3, X &macfw_enable, 0, "Enable macfw"); XSYSCTL_INT(_net_inet_macfw, OID_AUTO, log, CTLFLAG_RW | CTLFLAG_SECURE3, X &macfw_log, 0, "Log spoof attempts"); XSYSCTL_NODE(_net_inet_macfw, OID_AUTO, stat, CTLFLAG_RW, 0, "Statistics"); XSYSCTL_UINT(_net_inet_macfw_stat, OID_AUTO, unknown, CTLFLAG_RD, X &macfw_stat_unknown, 0, "Unknown"); XSYSCTL_PROC(_net_inet_macfw_stat, OID_AUTO, pass, CTLTYPE_UINT|CTLFLAG_RD, X 0, __offsetof(struct macfw_entry, macfwe_stat_pass), macfw_sysctl, "IU", "Pass"); XSYSCTL_PROC(_net_inet_macfw_stat, OID_AUTO, spoof_ip, CTLTYPE_UINT|CTLFLAG_RD, X 0, __offsetof(struct macfw_entry, macfwe_stat_spoof_ip), macfw_sysctl, "IU", "Spoofed IP"); XSYSCTL_PROC(_net_inet_macfw_stat, OID_AUTO, spoof_mac, CTLTYPE_UINT|CTLFLAG_RD, X 0, __offsetof(struct macfw_entry, macfwe_stat_spoof_mac), macfw_sysctl, "IU", "Spoofed MAC"); X Xstatic int macfw_sysctl(SYSCTL_HANDLER_ARGS) X{ X struct macfw_entry *e; X unsigned int r = 0; X X sx_slock(&macfw_sxlock); X RB_FOREACH(e, macfw_in_tree, &macfw_in_q) { X r += *(unsigned int*)(((char*)e) + arg2); X } X sx_sunlock(&macfw_sxlock); X X return (SYSCTL_OUT(req, &r, sizeof(r))); X} X Xstatic int macfwe_in_cmp(struct macfw_entry *a, struct macfw_entry *b) X{ X if (ntohl(a->macfwe_in.s_addr) > ntohl(b->macfwe_in.s_addr)) X return (1); X if (ntohl(a->macfwe_in.s_addr) < ntohl(b->macfwe_in.s_addr)) X return (-1); X return (0); X} X Xstatic int macfwe_ether_cmp(struct macfw_entry *a, struct macfw_entry *b) X{ X int i; X X for (i = 0; i < ETHER_ADDR_LEN; ++i) { X if (a->macfwe_ether.octet[i] > b->macfwe_ether.octet[i]) X return (1); X if (a->macfwe_ether.octet[i] < b->macfwe_ether.octet[i]) X return (-1); X } X X return (0); X} X Xstatic void macfw_flush(void) X{ X struct macfw_in_tree old_macfw_in_q; X struct macfw_entry *e; X X sx_xlock(&macfw_sxlock); X old_macfw_in_q = macfw_in_q; X RB_INIT(&macfw_in_q); X RB_INIT(&macfw_ether_q); X macfw_ticket++; X sx_xunlock(&macfw_sxlock); X X while ((e = RB_MIN(macfw_in_tree, &old_macfw_in_q)) != NULL) { X RB_REMOVE(macfw_in_tree, &old_macfw_in_q, e); X uma_zfree(macfw_entry_zone, e); X } X} X Xstatic int macfw_ioctl(struct cdev *dev, u_long cmd, caddr_t addr, int flags, struct thread *td) X{ X struct macfwioc_rule *rule; X struct macfw_entry *e; X int err = 0; X X if (!(flags & FWRITE)) { X switch(cmd) { X case MACFWIOCGETRULE: X break; X default: X return (EACCES); X } X } X X rule = (struct macfwioc_rule*) addr; X X switch(cmd) { X case MACFWIOCFLUSH: X macfw_flush(); X break; X case MACFWIOCZERO: X atomic_store_rel_int(&macfw_stat_unknown, 0); X sx_slock(&macfw_sxlock); X RB_FOREACH(e, macfw_in_tree, &macfw_in_q) { X atomic_store_rel_int(&e->macfwe_stat_pass, 0); X atomic_store_rel_int(&e->macfwe_stat_spoof_ip, 0); X atomic_store_rel_int(&e->macfwe_stat_spoof_mac, 0); X } X sx_sunlock(&macfw_sxlock); X break; X case MACFWIOCADDRULE: X e = uma_zalloc(macfw_entry_zone, M_WAITOK | M_ZERO); X e->macfwe_in = rule->mr_in; X e->macfwe_ether = rule->mr_ether; X X sx_xlock(&macfw_sxlock); X if (RB_INSERT(macfw_in_tree, &macfw_in_q, e) != NULL) { X err = EEXIST; X#ifdef MACFW_DEBUG X log(LOG_DEBUG, MACFW_NAME ": MACFWIOCADDRULE: IP exist: %s\n", X inet_ntoa(rule->mr_in)); X#endif X } else if (RB_INSERT(macfw_ether_tree, &macfw_ether_q, e) != NULL){ X RB_REMOVE(macfw_in_tree, &macfw_in_q, e); X err = EEXIST; X#ifdef MACFW_DEBUG X log(LOG_DEBUG, MACFW_NAME ": MACFWIOCADDRULE: MAC exist: %*D\n", X ETHER_ADDR_LEN, (u_char *)(rule->mr_ether.octet), ":"); X#endif X } else { X macfw_ticket++; X } X sx_xunlock(&macfw_sxlock); X X if (err != 0) { X#ifdef MACFW_DEBUG X log(LOG_DEBUG, MACFW_NAME ": MACFWIOCADDRULE: ticket = %d, err = %d, %s <-> %*D\n", X rule->mr_ticket, X err, X inet_ntoa(rule->mr_in), X ETHER_ADDR_LEN, (u_char *)(rule->mr_ether.octet), ":"); X#endif X uma_zfree(macfw_entry_zone, e); X } else if (macfw_log) { X log(LOG_INFO, MACFW_NAME ": rule: %s <-> %*D\n", X inet_ntoa(rule->mr_in), X ETHER_ADDR_LEN, (u_char *)(rule->mr_ether.octet), ":"); X } X break; X case MACFWIOCGETRULE: X sx_slock(&macfw_sxlock); X X if (rule->mr_ticket == 0) { X e = RB_MIN(macfw_in_tree, &macfw_in_q); X } else if (rule->mr_ticket == macfw_ticket) { X struct macfw_entry e_key; X X bzero(&e_key, sizeof(struct macfw_entry)); X e_key.macfwe_in = rule->mr_in; X e_key.macfwe_ether = rule->mr_ether; X e = RB_FIND(macfw_in_tree, &macfw_in_q, &e_key); X if (e != NULL) X e = RB_NEXT(macfw_in_tree, &macfw_in_q, e); X } else { X e = NULL; X err = EINVAL; X } X X if (e != NULL) { X rule->mr_ticket = macfw_ticket; X rule->mr_in = e->macfwe_in; X rule->mr_ether = e->macfwe_ether; X rule->mr_stat_pass = atomic_load_acq_int(&e->macfwe_stat_pass); X rule->mr_stat_spoof_ip = atomic_load_acq_int(&e->macfwe_stat_spoof_ip); X rule->mr_stat_spoof_mac = atomic_load_acq_int(&e->macfwe_stat_spoof_mac); X } else { X bzero(rule, sizeof(struct macfwioc_rule)); X err = ENOENT; X } X sx_sunlock(&macfw_sxlock); X#ifdef MACFW_DEBUG X log(LOG_DEBUG, MACFW_NAME ": MACFWIOCGETRULE: ticket = %d, err = %d, %s <-> %*D\n", X rule->mr_ticket, X err, X inet_ntoa(rule->mr_in), X ETHER_ADDR_LEN, (u_char *)(rule->mr_ether.octet), ":"); X#endif X break; X default: X return (ENODEV); X } X X return (err); X} X Xstatic int macfw_in(void *arg, struct mbuf **m, struct ifnet *ifp, X int dir, struct inpcb *inp) X{ X struct macfw_entry e, *r; X union { X struct in_addr macfwe_in; X struct ether_addr macfwe_ether; X } e_spoof; X struct m_tag *mtag_ether_shost; X struct ip *ip; X enum { MACFW_PASS, MACFW_SPOOF_IP, MACFW_SPOOF_MAC } err = MACFW_PASS; X X if (macfw_enable == 0) X return (0); X X mtag_ether_shost = m_tag_locate(*m, MTAG_ETHER, MTAG_ETHER_SHOST, NULL); X if (mtag_ether_shost == NULL) X return (0); X e.macfwe_ether = *(struct ether_addr*)(mtag_ether_shost + 1); X m_tag_delete(*m, mtag_ether_shost); X X ip = mtod(*m, struct ip *); X if (ip->ip_v != 4) X return (0); X e.macfwe_in = ip->ip_src; X X sx_slock(&macfw_sxlock); X r = RB_FIND(macfw_in_tree, &macfw_in_q, &e); X if (r == NULL) { X r = RB_FIND(macfw_ether_tree, &macfw_ether_q, &e); X if (r != NULL) { X err = MACFW_SPOOF_IP; X e_spoof.macfwe_in = r->macfwe_in; X atomic_add_int(&r->macfwe_stat_spoof_ip, 1); X } else { X atomic_add_int(&macfw_stat_unknown, 1); X } X } else { X if (macfwe_ether_cmp(r, &e) != 0) { X err = MACFW_SPOOF_MAC; X e_spoof.macfwe_ether = r->macfwe_ether; X atomic_add_int(&r->macfwe_stat_spoof_mac, 1); X } else { X atomic_add_int(&r->macfwe_stat_pass, 1); X } X } X sx_sunlock(&macfw_sxlock); X X if (err == MACFW_PASS) X return (0); X X if (macfw_log) { X switch(err) { X case MACFW_PASS: X /* make gcc happy */ X break; X case MACFW_SPOOF_IP: X#define __INET_NTOA__PRINTF(a) ((unsigned char *)&(a))[0] & 0xff, \ X ((unsigned char *)&(a))[1] & 0xff, \ X ((unsigned char *)&(a))[2] & 0xff, \ X ((unsigned char *)&(a))[3] & 0xff X log(LOG_ERR, MACFW_NAME ": %*D changed IP: " X "%d.%d.%d.%d -> %d.%d.%d.%d on %s\n", X ETHER_ADDR_LEN, (u_char *)(e.macfwe_ether.octet), ":", X __INET_NTOA__PRINTF(e_spoof.macfwe_in), X __INET_NTOA__PRINTF(e.macfwe_in), X ifp->if_xname); X#undef __INET_NTOA__PRINTF X break; X case MACFW_SPOOF_MAC: X log(LOG_ERR, MACFW_NAME ": %s changed MAC: " X "%*D -> %*D on %s\n", X inet_ntoa(e.macfwe_in), X ETHER_ADDR_LEN, (u_char *)(e_spoof.macfwe_ether.octet), ":", X ETHER_ADDR_LEN, (u_char *)(e.macfwe_ether.octet), ":", X ifp->if_xname); X break; X } X } X X m_freem(*m); X *m = NULL; X return (EACCES); X} X Xstatic int macfw_add_pfil_hook(void) X{ X struct pfil_head *pfil_h; X X if (macfw_pfil_hooked != 0) X return (EEXIST); X X pfil_h = pfil_head_get(PFIL_TYPE_AF, AF_INET); X if (pfil_h == NULL) X return (ESRCH); X pfil_add_hook(macfw_in, NULL, PFIL_IN | PFIL_WAITOK, pfil_h); X X macfw_pfil_hooked = 1; X return (0); X} X Xstatic int macfw_remove_pfil_hook(void) X{ X struct pfil_head *pfil_h; X X if (macfw_pfil_hooked == 0) X return (ESRCH); X X pfil_h = pfil_head_get(PFIL_TYPE_AF, AF_INET); X if (pfil_h == NULL) X return (ESRCH); X pfil_remove_hook(macfw_in, NULL, PFIL_IN | PFIL_WAITOK, pfil_h); X X macfw_pfil_hooked = 0; X return (0); X} X X Xstatic int macfw_modevent(module_t mod, int type, void *unused) X{ X int err = 0; X X switch (type) { X case MOD_LOAD: X RB_INIT(&macfw_in_q); X RB_INIT(&macfw_ether_q); X sx_init(&macfw_sxlock, "arp-antispoof sx lock"); X macfw_entry_zone = uma_zcreate("macfw entry", X sizeof(struct macfw_entry), NULL, NULL, NULL, NULL, X UMA_ALIGN_PTR, 0); X macfw_dev = make_dev(&macfw_devsw, 0, UID_ROOT, GID_WHEEL, X S_IRUSR | S_IWUSR | S_IRGRP, MACFW_NAME); X err = macfw_add_pfil_hook(); X#ifdef MACFW_DEBUG X macfw_log = 1; X log(LOG_DEBUG, MACFW_NAME " loaded\n"); X#endif X break; X case MOD_UNLOAD: X err = macfw_remove_pfil_hook(); X destroy_dev(macfw_dev); X macfw_flush(); X sx_destroy(&macfw_sxlock); X uma_zdestroy(macfw_entry_zone); X#ifdef MACFW_DEBUG X log(LOG_DEBUG, MACFW_NAME " unloaded\n"); X#endif X break; X default: X return EOPNOTSUPP; X break; X } X X return (err); X} X X Xstatic moduledata_t macfw_mod = { X MACFW_NAME, X macfw_modevent, X 0 X}; X XDECLARE_MODULE(macfw, macfw_mod, SI_SUB_PROTO_IFATTACHDOMAIN, SI_ORDER_ANY); XMODULE_VERSION(macfw, 1); X END-of-macfw/module/macfw.c echo x - macfw/module/macfwvar.h sed 's/^X//' >macfw/module/macfwvar.h << 'END-of-macfw/module/macfwvar.h' X/*- X * Copyright (c) 2006 Gleb Kurtsov X * All rights reserved. X * X * Redistribution and use in source and binary forms, with or without X * modification, are permitted provided that the following conditions X * are met: X * 1. Redistributions of source code must retain the above copyright X * notice, this list of conditions and the following disclaimer. X * 2. Redistributions in binary form must reproduce the above copyright X * notice, this list of conditions and the following disclaimer in the X * documentation and/or other materials provided with the distribution. X * X * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND X * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE X * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE X * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE X * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL X * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS X * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) X * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT X * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY X * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF X * SUCH DAMAGE. X * X */ X X#ifndef __MACFWVAR_H X#define __MACFWVAR_H X X#include X#include X#include X#include X Xstruct macfwioc_rule { X int mr_ticket; X struct ether_addr mr_ether; X struct in_addr mr_in; X unsigned int mr_stat_pass; X unsigned int mr_stat_spoof_ip; X unsigned int mr_stat_spoof_mac; X}; X X#define MACFWIOCFLUSH _IO ('Z', 1) X#define MACFWIOCADDRULE _IOW ('Z', 2, struct macfwioc_rule) X#define MACFWIOCGETRULE _IOWR('Z', 3, struct macfwioc_rule) X#define MACFWIOCZERO _IO ('Z', 4) X X X#endif X END-of-macfw/module/macfwvar.h echo x - macfw/module/patch-sys-macfw sed 's/^X//' >macfw/module/patch-sys-macfw << 'END-of-macfw/module/patch-sys-macfw' XIndex: net/ethernet.h X=================================================================== XRCS file: /pub/mirror/FreeBSD-CVS/src/sys/net/ethernet.h,v Xretrieving revision 1.24 Xdiff -u -r1.24 ethernet.h X--- net/ethernet.h 5 Oct 2004 19:28:52 -0000 1.24 X+++ net/ethernet.h 21 Jan 2006 16:36:26 -0000 X@@ -346,6 +346,9 @@ X X #ifdef _KERNEL X X+#define MTAG_ETHER 1080579719 X+#define MTAG_ETHER_SHOST 0 X+ X struct ifnet; X struct mbuf; X struct rtentry; XIndex: net/if_ethersubr.c X=================================================================== XRCS file: /pub/mirror/FreeBSD-CVS/src/sys/net/if_ethersubr.c,v Xretrieving revision 1.212 Xdiff -u -r1.212 if_ethersubr.c X--- net/if_ethersubr.c 18 Jan 2006 14:24:39 -0000 1.212 X+++ net/if_ethersubr.c 21 Jan 2006 16:34:46 -0000 X@@ -726,6 +726,18 @@ X return; X } X X+#ifdef INET X+ if (ether_type == ETHERTYPE_IP) { X+ struct m_tag *mtag_shost; X+ X+ mtag_shost = m_tag_alloc(MTAG_ETHER, MTAG_ETHER_SHOST, ETHER_ADDR_LEN, M_NOWAIT); X+ if (mtag_shost != NULL) { X+ memcpy(mtag_shost + 1, eh->ether_shost, ETHER_ADDR_LEN); X+ m_tag_prepend(m, mtag_shost); X+ } X+ } X+#endif X+ X /* Strip off Ethernet header. */ X m_adj(m, ETHER_HDR_LEN); X END-of-macfw/module/patch-sys-macfw exit --BXVAT5kNtrzKuDFl-- From owner-freebsd-net@FreeBSD.ORG Mon Nov 13 22:24:00 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 DA5FF16A49E; Mon, 13 Nov 2006 22:24:00 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8022243EC0; Mon, 13 Nov 2006 22:22:12 +0000 (GMT) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id kADMM9iH041530; Mon, 13 Nov 2006 17:22:09 -0500 (EST) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.6/8.13.3) with ESMTP id kADMM8er046074 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Nov 2006 17:22:09 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <200611132222.kADMM8er046074@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 13 Nov 2006 17:22:20 -0500 To: Ivan Voras , freebsd-stable@freebsd.org From: Mike Tancsa In-Reply-To: References: <2a41acea0611081719h31be096eu614d2f2325aff511@mail.gmail.com> <200611091536.kA9FaltD018819@lava.sentex.ca> <45534E76.6020906@samsco.org> <200611092200.kA9M0q1E020473@lava.sentex.ca> <200611102004.kAAK4iO9027778@lava.sentex.ca> <2a41acea0611101400w5b8cef40ob84ed6de181f3e2c@mail.gmail.com> <200611102221.kAAML6ol028630@lava.sentex.ca> <455570D8.6070000@samsco.org> <200611120412.kAC4CuIB035746@lava.sentex.ca> <45574ECA.4080207@samsco.org> <200611130040.kAD0etbp040637@lava.sentex.ca> <4557CECD.2000609@samsco.org> <200611130158.kAD1wdKE040908@lava.sentex.ca> <4557EF13.9060305@samsco.org> <200611130454.kAD4sZwe041556@lava.sentex.ca> <4557FF7A.8020704@samsco.org> <200611131248.kADCmieP043730@lava.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner4 X-Virus-Status: Clean Cc: freebsd-net@freebsd.org Subject: Re: Proposed 6.2 em RELEASE patch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Nov 2006 22:24:01 -0000 At 12:50 PM 11/13/2006, Ivan Voras wrote: >Mike Tancsa wrote: > > At 12:15 AM 11/13/2006, Scott Long wrote: > > > >> Is this with EM_INTR_FAST enabled also? > > > > Yes. Havent done the stock case yet, but will do so later today. > >Do you have a comparison with Linux under the same circumstances? I had a disk with 64bit already installed. I will try with 32bit tomorrow. I can also try FreeBSD AMD64 on the box to see how it does. ifstat gives a bit of an odd output, but its the same sort of pattern where adding a second stream in the same direction, slows down the first one. On the box R2 [root@amd64 ifstat-1.1]# ifstat -b eth0 eth1 eth3 eth4 Kbps in Kbps out Kbps in Kbps out Kbps in Kbps out Kbps in Kbps out 0.00 0.00 0.00 0.00 0.00 0.00 4.89 3.74 0.00 0.00 0.00 0.00 0.00 0.00 0.50 1.45 0.00 0.00 0.00 0.00 0.00 0.00 1.00 1.45 160965.0 0.00 0.00 0.00 0.00 0.00 0.83 1.95 0.00 0.00 0.00 272056.4 0.00 0.00 1.00 1.45 393994.2 0.00 0.00 0.00 0.00 0.00 5.47 1.45 0.00 0.00 0.00 393543.7 0.00 0.00 4.25 1.45 392911.0 0.00 0.00 0.00 0.00 0.00 2.50 1.45 0.00 0.00 0.50 392756.4 0.00 0.00 1.25 1.45 392626.7 0.00 0.00 0.00 0.00 0.00 1.75 1.45 0.00 0.00 0.00 393233.9 0.00 0.00 6.44 1.45 424068.1 0.00 0.00 0.00 0.00 0.00 1.74 1.45** 0.00 0.00 0.00 460503.1 0.00 0.00 2.72 1.45 509218.1 0.00 0.00 0.00 0.00 0.00 0.99 1.45 0.00 0.00 0.00 507800.4 0.00 0.00 0.50 1.45 502649.5 0.00 0.00 0.00 0.00 0.00 1.00 1.45 0.00 0.00 0.50 507537.1 0.00 0.00 0.50 1.46 519717.9 0.00 0.00 0.00 0.00 0.00 1.00 1.45 0.00 0.00 0.00 525973.4 0.00 0.00 0.50 1.46 520609.0 0.00 0.00 0.00 0.00 0.00 1.00 1.45 0.00 0.00 0.00 517888.6 0.00 0.00 0.50 1.45 525957.3 0.00 0.00 0.00 0.00 0.00 1.00 1.46 0.00 0.00 0.00 524119.9 0.00 0.00 0.50 1.45 522671.1 0.00 0.00 0.00 0.00 0.00 0.99 1.44 0.00 0.00 0.00 494008.7 0.00 0.00 0.50 1.45 390666.3 0.00 0.00 0.00 0.00 0.00 1.00 1.45 0.00 0.00 0.00 273779.6 0.00 0.00 0.50 1.45 0.00 0.00 0.00 0.00 0.00 0.00 1.00 1.45 0.00 0.00 0.00 0.00 0.00 0.00 0.50 1.45 [root@amd64 ifstat-1.1]# I added the second stream, going in the same direction at ** On one of the targets running netreceive you can see the impact. [tyan-1u]# ifstat -b rl0 bge0 Kbps in Kbps out Kbps in Kbps out 0.94 1.42 182716.2 0.00 0.47 1.05 182299.5 0.00 0.94 1.05 182493.4 0.33 0.94 2.09 182588.7 0.00 0.94 1.05 181959.8 0.00 0.47 1.05 104949.7 0.00 0.94 1.05 95674.27 0.00 0.47 1.05 95930.79 0.00 0.94 1.05 98329.93 0.00 0.94 1.05 97940.21 0.00 0.94 1.05 100636.9 0.00 0.47 1.05 99879.34 0.00 ^C [tyan-1u]# When the packets are bi-directional, the impact is not as great in LINUX as it is on FreeBSD [root@amd64 ifstat-1.1]# ifstat -b eth0 eth1 eth3 eth4 Kbps in Kbps out Kbps in Kbps out Kbps in Kbps out Kbps in Kbps out 0.00 0.00 0.00 0.00 0.00 0.00 3.65 10.81 0.00 0.00 0.00 0.00 0.00 0.00 0.50 1.45 0.00 0.00 0.00 0.00 0.00 0.00 0.83 1.95 0.00 0.00 0.00 0.00 0.00 0.00 1.50 8.03 0.00 0.00 0.00 0.00 0.00 0.00 0.50 1.45 0.00 0.00 0.00 0.00 0.00 0.00 1.00 1.45 0.00 230009.2 0.00 0.00 0.00 0.00 2.83 51.22 0.00 0.00 334969.3 0.00 0.00 0.00 1.00 1.45 0.00 369184.5 0.00 0.00 0.00 0.00 0.50 1.45 0.00 0.00 369294.2 0.00 0.00 0.00 3.33 51.10 0.00 367348.7 0.00 0.00 0.00 0.00 0.50 1.45 0.00 0.00 367185.5 0.00 0.00 0.00 1.00 1.45 2541.17 368707.6 0.00 0.00 0.00 0.00 2.82 51.12 0.00 0.00 363265.6 95798.38 0.00 0.00 0.99 1.44 330239.4 357706.3 0.00 0.00 0.00 0.00 0.50 1.45 0.00 0.00 354181.1 326599.7 0.00 0.00 4.11 51.17 328691.7 356129.1 0.00 0.00 0.00 0.00 0.50 1.44 0.00 0.00 358321.6 330567.1 0.00 0.00 1.50 1.45 329516.7 342389.2 0.00 0.00 0.00 0.00 0.99 14.99 0.00 0.00 334539.9 330647.5 0.00 0.00 0.99 1.44 330982.0 326772.6 0.00 0.00 0.00 0.00 0.50 1.44 0.00 0.00 329472.7 333109.3 0.00 0.00 2.32 14.45 324457.4 327537.4 0.00 0.00 0.00 0.00 0.50 1.44 0.00 0.00 329367.2 317784.0 0.00 0.00 0.99 1.44 308120.8 333789.8 0.00 0.00 0.00 0.00 1.80 20.78 0.00 0.00 331200.2 316116.3 0.00 0.00 1.00 1.45 370504.6 88001.99 0.00 0.00 0.00 0.00 0.50 1.44 0.00 0.00 0.50 392417.6 0.00 0.00 2.82 21.76 394057.2 0.00 0.00 0.00 0.00 0.00 0.83 1.95 0.00 0.00 0.00 394048.2 0.00 0.00 1.00 1.45 394306.3 0.00 0.00 0.00 0.00 0.00 3.66 52.56 0.00 0.00 0.00 393960.8 0.00 0.00 1.00 1.45 373321.8 0.00 0.00 0.00 0.00 0.00 0.50 1.45 0.00 0.00 0.00 261093.7 0.00 0.00 2.33 9.66 0.00 0.00 0.00 0.00 0.00 0.00 0.50 1.45 0.00 0.00 0.00 0.00 0.00 0.00 0.50 1.45 The box is totally responsive throughout with no packet loss on the management interface.... However, it seems quite a bit slower than FreeBSD when its tweaked with ADAPTIVE_GIANT removed... But again, this is 64bit so not quite apples to apples yet. Also, I need to check the default driver config to see if their NAPI or whatever its called is enabled. More tests to come. ---Mike >_______________________________________________ >freebsd-stable@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-stable >To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Tue Nov 14 00:07:36 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 D4A5216A412; Tue, 14 Nov 2006 00:07:36 +0000 (UTC) (envelope-from miroslav@svishtov.net) Received: from mail.svishtov.net (mail.svishtov.net [85.217.192.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id E32FD43D64; Tue, 14 Nov 2006 00:07:33 +0000 (GMT) (envelope-from miroslav@svishtov.net) X-Spam-Status: No, hits=4.8 required=7.5 tests=AWL: -1.141,BAYES_99: 4.07,HTML_50_60: 0.539, HTML_MESSAGE: 0.001,RCVD_NUMERIC_HELO: 1.348 X-Spam-Level: **** Received: from 85.217.217.217 ([85.217.217.217]) by mail.svishtov.net (Kerio MailServer 6.1.1) for miroslav@svishtov.net; Tue, 14 Nov 2006 01:15:23 +0200 From: =?utf-8?Q?=D0=9C=D0=B8=D1=80=D0=BE=D1=81=D0=BB=D0=B0=D0=B2?= =?utf-8?Q?_=D0=A1=D0=BB=D0=B0=D0=B2=D0=BA=D0=BE=D0=B2?= To: Mike Tancsa ,Ivan Voras ,freebsd-stable@freebsd.org In-Reply-To: <200611132222.kADMM8er046074@lava.sentex.ca> Message-ID: <20061113231523.b6d6a902@mail.svishtov.net> Date: Tue, 14 Nov 2006 01:15:23 +0200 X-Mailer: Kerio MailServer 6.1.1 WebMail X-User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: Proposed 6.2 em RELEASE patch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 14 Nov 2006 00:07:36 -0000 Hey. I've got one new machine for testing for 1-2 days... here's some = output.. With the latest drivers (cvsup'ed from yesterday) Send box: 2x Intel Xeon 5110 (1.6GHz), SuperMicro X7-DBE, Intel Pro/1000= MT Server Adapter CPU: Intel(R) Xeon(R) CPU 5110 @ 1.60GHz (1600.01-MHz 686-cl= ass CPU) Origin =3D "GenuineIntel" Id =3D 0x6f6 Stepping =3D 6 Features=3D0xbfebfbff Features2=3D0x4e33d,CX16,,,> AMD Features=3D0x20100000 AMD Features2=3D0x1 Cores per package: 2 real memory =3D 1073086464 (1023 MB) avail memory =3D 1040961536 (992 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs Recv box: AMD Sempron 3800+, (Some nVidia chipset.. maybe 4), Intel Pro/= 1000 PT Desktop Adapter system load is around 2 EM=5FINTR=5FFAST is defined (if not defined load is higher..5-6) [root@serverx ~]# iperf -c 172.16.133.2 -t 9999999 ------------------------------------------------------------ Client connecting to 172.16.133.2, TCP port 5001 TCP window size: 129 KByte (default) ------------------------------------------------------------ [ 3] local 172.16.133.1 port 58425 connected with 172.16.133.2 port 500= 1 ^C[ 3] 0.0-48.1 sec 4.87 GBytes 869 Mbits/sec [root@serverx ~]# ifstat -b em0 em2 Kbps in Kbps out Kbps in Kbps out 46117.87 885607.5 12.76 1.45 45892.97 879815.3 22.61 1.07 ifstat: warning: rollover for interface em0, reinitialising. 0.00 0.00 581.95 1.07 46436.31 890665.0 700.36 2.27 46062.60 884031.1 794.26 1.07 46576.76 893408.4 846.86 1.07 47117.81 903658.6 859.40 1.07 46141.71 885471.3 867.05 1.07 45926.92 881372.1 363.41 1.07 46003.51 883432.4 35.64 1.07 46052.45 884164.9 28.41 1.07 45863.03 880448.1 12.66 1.07 46152.73 885549.1 33.71 1.07 46737.09 896811.9 39.02 1.07 46188.92 885847.3 58.92 1.07 45770.39 878602.0 19.24 1.07 46743.62 896967.0 34.72 1.07 46412.27 890970.9 34.65 1.07 46322.73 888747.3 26.61 1.07 46002.64 882522.8 23.69 1.07 46450.56 891662.8 26.91 1.07 45991.55 882605.9 37.92 1.07 46067.28 883815.5 34.82 1.07 46120.28 885357.6 33.79 1.07 46133.17 885316.5 21.56 1.07 46700.43 895554.6 10.12 1.49 45476.68 873874.2 15.78 1.07 45791.88 878655.9 15.99 1.07 46344.84 889292.8 7.72 1.07 46577.31 893572.1 10.49 1.07 46065.09 884277.6 8.77 1.07 46566.97 892898.4 6.07 1.07 46232.46 886846.8 13.02 1.07 46165.29 886647.9 7.47 1.07 46080.80 884256.7 14.54 1.07 46757.57 896977.8 14.59 1.07 46182.78 885594.3 10.30 1.07 46103.81 885661.0 13.95 1.07 46469.89 891511.3 13.85 1.07 46470.86 891611.1 11.42 1.07 From owner-freebsd-net@FreeBSD.ORG Tue Nov 14 00:50:54 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 2E76316A403; Tue, 14 Nov 2006 00:50:54 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7814643D8D; Tue, 14 Nov 2006 00:50:53 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id kAE0oaiA086650; Mon, 13 Nov 2006 17:50:42 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <455912DC.1020101@samsco.org> Date: Mon, 13 Nov 2006 17:50:36 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.7) Gecko/20060910 SeaMonkey/1.0.5 MIME-Version: 1.0 To: Mike Tancsa References: <2a41acea0611081719h31be096eu614d2f2325aff511@mail.gmail.com> <200611091536.kA9FaltD018819@lava.sentex.ca> <45534E76.6020906@samsco.org> <200611092200.kA9M0q1E020473@lava.sentex.ca> <200611102004.kAAK4iO9027778@lava.sentex.ca> <2a41acea0611101400w5b8cef40ob84ed6de181f3e2c@mail.gmail.com> <200611102221.kAAML6ol028630@lava.sentex.ca> <455570D8.6070000@samsco.org> <200611120412.kAC4CuIB035746@lava.sentex.ca> <45574ECA.4080207@samsco.org> <200611130040.kAD0etbp040637@lava.sentex.ca> <4557CECD.2000609@samsco.org> <200611130158.kAD1wdKE040908@lava.sentex.ca> <4557EF13.9060305@samsco.org> <200611130454.kAD4sZwe041556@lava.sentex.ca> <4557FF7A.8020704@samsco.org> <200611131248.kADCmieP043730@lava.sentex.ca> <200611132222.kADMM8er046074@lava.sentex.ca> In-Reply-To: <200611132222.kADMM8er046074@lava.sentex.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org, Ivan Voras Subject: Re: Proposed 6.2 em RELEASE patch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 14 Nov 2006 00:50:54 -0000 Mike Tancsa wrote: > At 12:50 PM 11/13/2006, Ivan Voras wrote: >> Mike Tancsa wrote: >> > At 12:15 AM 11/13/2006, Scott Long wrote: >> > >> >> Is this with EM_INTR_FAST enabled also? >> > >> > Yes. Havent done the stock case yet, but will do so later today. >> >> Do you have a comparison with Linux under the same circumstances? > > I had a disk with 64bit already installed. I will try with 32bit > tomorrow. I can also try FreeBSD AMD64 on the box to see how it does. > > ifstat gives a bit of an odd output, but its the same sort of pattern > where adding a second stream in the same direction, slows down the first > one. On the box R2 ... > > The box is totally responsive throughout with no packet loss on the > management interface.... However, it seems quite a bit slower than > FreeBSD when its tweaked with ADAPTIVE_GIANT removed... But again, this > is 64bit so not quite apples to apples yet. Also, I need to check the > default driver config to see if their NAPI or whatever its called is > enabled. More tests to come. > > ---Mike More excellent data, thanks. I have some changes on the drawing board that should significantly improve forwarding and bridging in the em driver. Do you have a limit on how much more time you can spend on these tests? It might be a week or more before I have anything that can be tested. Scott From owner-freebsd-net@FreeBSD.ORG Tue Nov 14 03:13:45 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 DD43F16A417; Tue, 14 Nov 2006 03:13:45 +0000 (UTC) (envelope-from michael@staff.openaccess.org) Received: from smtp.openaccess.org (smtp.openaccess.org [66.165.52.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id D6FA543D62; Tue, 14 Nov 2006 03:13:43 +0000 (GMT) (envelope-from michael@staff.openaccess.org) Received: from localhost (unknown [66.165.52.46]) by smtp.openaccess.org (Postfix) with ESMTP id 1BB336D4413; Mon, 13 Nov 2006 19:13:43 -0800 (PST) X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999.99 required=5 tests=[AWL=-0.549, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_OBFUSCATE_10_20=1.77] Received: from smtp.openaccess.org ([66.165.52.46]) by localhost (smtp.openaccess.org [66.165.52.46]) (amavisd-new, port 10024) with ESMTP id tjAnJiFd7Ho1; Mon, 13 Nov 2006 19:12:20 -0800 (PST) Received: from [192.168.2.151] (staff.openaccess.org [216.57.214.98]) by smtp.openaccess.org (Postfix) with ESMTP id 182946D42F2; Mon, 13 Nov 2006 19:12:20 -0800 (PST) In-Reply-To: <20061113231523.b6d6a902@mail.svishtov.net> References: <20061113231523.b6d6a902@mail.svishtov.net> Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <55334658-D4A4-47AE-AF76-B76135881654@staff.openaccess.org> From: Michael DeMan Date: Mon, 13 Nov 2006 19:12:19 -0800 To: =?UTF-8?B?0JzQuNGA0L7RgdC70LDQsiDQodC70LDQstC60L7Qsg==?= X-Mailer: Apple Mail (2.752.2) Content-Type: text/plain; charset=UTF-8; delsp=yes; format=flowed Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org, Ivan Voras , Mike Tancsa Subject: Re: Proposed 6.2 em RELEASE patch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 14 Nov 2006 03:13:46 -0000 Hi All, Unfortunately our company hasn't had the resources to help FreeBSD =20 much over the years, but I do want to say thank you to the folks who =20 are helping sort out this issue with the em driver. That Intel gigabit interface is very, very common on server hardware =20 nowadays and it means a lot to us to make sure it (and FreeBSD 6.2 in =20= general) are stable. - mike Michael F. DeMan Director of Technology OpenAccess Network Services Bellingham, WA 98225 michael@staff.openaccess.org 360-647-0785 --- If your question is support related, please contact =20 support@openaccess.org directly for faster assistance --- On Nov 13, 2006, at 3:15 PM, =D0=9C=D0=B8=D1=80=D0=BE=D1=81=D0=BB=D0=B0=D0= =B2 =D0=A1=D0=BB=D0=B0=D0=B2=D0=BA=D0=BE=D0=B2 wrote: > Hey. I've got one new machine for testing for 1-2 days... here's =20 > some output.. > > With the latest drivers (cvsup'ed from yesterday) > > Send box: 2x Intel Xeon 5110 (1.6GHz), SuperMicro X7-DBE, Intel Pro/=20= > 1000 MT Server Adapter > > CPU: Intel(R) Xeon(R) CPU 5110 @ 1.60GHz (1600.01-MHz =20 > 686-class CPU) > Origin =3D "GenuineIntel" Id =3D 0x6f6 Stepping =3D 6 > =20 > Features=3D0xbfebfbff GE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE=20= > > > =20 > Features2=3D0x4e33d,CX16,,,= =20 > > > AMD Features=3D0x20100000 > AMD Features2=3D0x1 > Cores per package: 2 > real memory =3D 1073086464 (1023 MB) > avail memory =3D 1040961536 (992 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > > > Recv box: AMD Sempron 3800+, (Some nVidia chipset.. maybe 4), Intel =20= > Pro/1000 PT Desktop Adapter > > system load is around 2 > EM_INTR_FAST is defined (if not defined load is higher..5-6) > > [root@serverx ~]# iperf -c 172.16.133.2 -t 9999999 > ------------------------------------------------------------ > Client connecting to 172.16.133.2, TCP port 5001 > TCP window size: 129 KByte (default) > ------------------------------------------------------------ > [ 3] local 172.16.133.1 port 58425 connected with 172.16.133.2 =20 > port 5001 > ^C[ 3] 0.0-48.1 sec 4.87 GBytes 869 Mbits/sec > > > [root@serverx ~]# ifstat -b > em0 em2 > Kbps in Kbps out Kbps in Kbps out > 46117.87 885607.5 12.76 1.45 > 45892.97 879815.3 22.61 1.07 > ifstat: warning: rollover for interface em0, reinitialising. > 0.00 0.00 581.95 1.07 > 46436.31 890665.0 700.36 2.27 > 46062.60 884031.1 794.26 1.07 > 46576.76 893408.4 846.86 1.07 > 47117.81 903658.6 859.40 1.07 > 46141.71 885471.3 867.05 1.07 > 45926.92 881372.1 363.41 1.07 > 46003.51 883432.4 35.64 1.07 > 46052.45 884164.9 28.41 1.07 > 45863.03 880448.1 12.66 1.07 > 46152.73 885549.1 33.71 1.07 > 46737.09 896811.9 39.02 1.07 > 46188.92 885847.3 58.92 1.07 > 45770.39 878602.0 19.24 1.07 > 46743.62 896967.0 34.72 1.07 > 46412.27 890970.9 34.65 1.07 > 46322.73 888747.3 26.61 1.07 > 46002.64 882522.8 23.69 1.07 > 46450.56 891662.8 26.91 1.07 > 45991.55 882605.9 37.92 1.07 > 46067.28 883815.5 34.82 1.07 > 46120.28 885357.6 33.79 1.07 > 46133.17 885316.5 21.56 1.07 > 46700.43 895554.6 10.12 1.49 > 45476.68 873874.2 15.78 1.07 > 45791.88 878655.9 15.99 1.07 > 46344.84 889292.8 7.72 1.07 > 46577.31 893572.1 10.49 1.07 > 46065.09 884277.6 8.77 1.07 > 46566.97 892898.4 6.07 1.07 > 46232.46 886846.8 13.02 1.07 > 46165.29 886647.9 7.47 1.07 > 46080.80 884256.7 14.54 1.07 > 46757.57 896977.8 14.59 1.07 > 46182.78 885594.3 10.30 1.07 > 46103.81 885661.0 13.95 1.07 > 46469.89 891511.3 13.85 1.07 > 46470.86 891611.1 11.42 1.07 > _______________________________________________ > 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 Tue Nov 14 16:20:24 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 4EA7716A494; Tue, 14 Nov 2006 16:20:24 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 853E943F70; Tue, 14 Nov 2006 16:09:19 +0000 (GMT) (envelope-from max@love2party.net) Received: from [88.64.186.21] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu5) with ESMTP (Nemesis), id 0ML25U-1Gk0qT1noA-0003As; Tue, 14 Nov 2006 17:09:09 +0100 From: Max Laier Organization: FreeBSD To: freebsd-hackers@freebsd.org Date: Tue, 14 Nov 2006 17:09:20 +0100 User-Agent: KMail/1.9.4 X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<%}*_BD U_or=\mOZf764&nYj=JYbR1PW0ud>|!~, , CPC.1-D$FG@0h3#'5"k{V]a~. X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: freebsd-net@freebsd.org Subject: ipv6 connection hash function wanted ... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 14 Nov 2006 16:20:24 -0000 --nextPart1529959.aSOhg96bU6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello, this one is something for people who know their math. Input: 2x128bit of address (lower ~80bit selectable by user) and 2x16bit=20 of ports (more or less selectable by user). Note that the "flow_id" is=20 not useable as several broken stack implementations do not set it=20 consistently - and it is user settable as well. Output: "int" hash value - by default we use the lower 8bit of it. Problems: Most of the input can be selected by a user meaning it is easy=20 to produce collisions. For legal connections, the lower 64bit are the=20 one with the highest entropy - in fact the upper 64bit might be the same=20 for many connections coming from/going to the same subnet. This function=20 will be used for every packet that is passed to a dynamic IPFW rule, so=20 efficiency is a concern. Any ideas? Any papers that deal with this problem? ref: sys/netinet/ip_fw2.c::hash_packet6 =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart1529959.aSOhg96bU6 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQBFWeo2XyyEoT62BG0RAv5YAJ99W3lFucWxtqwM2DffEMRd9B3DIgCdG5Nh 0cHxQBrsibVS6R+saGqA0mY= =l4Hy -----END PGP SIGNATURE----- --nextPart1529959.aSOhg96bU6-- From owner-freebsd-net@FreeBSD.ORG Tue Nov 14 16:36:35 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 3950416A412 for ; Tue, 14 Nov 2006 16:36:35 +0000 (UTC) (envelope-from twohey@cs.stanford.edu) Received: from smtp1.stanford.edu (smtp1.Stanford.EDU [171.67.22.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id B317443D62 for ; Tue, 14 Nov 2006 16:36:34 +0000 (GMT) (envelope-from twohey@cs.stanford.edu) Received: from smtp1.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 330504C155 for ; Tue, 14 Nov 2006 08:36:34 -0800 (PST) Received: from keeda.stanford.edu (keeda.Stanford.EDU [171.64.72.55]) by smtp1.stanford.edu (Postfix) with ESMTP id 16EE74C0A9 for ; Tue, 14 Nov 2006 08:36:34 -0800 (PST) Received: from twohey (helo=localhost) by keeda.stanford.edu with local-esmtp (Exim 4.63) (envelope-from ) id 1Gk1H0-0002jC-0y; Tue, 14 Nov 2006 08:36:34 -0800 Date: Tue, 14 Nov 2006 08:36:33 -0800 (PST) From: Paul Twohey X-X-Sender: twohey@keeda.stanford.edu To: Max Laier In-Reply-To: <200611141709.26644.max@love2party.net> Message-ID: References: <200611141709.26644.max@love2party.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-hackers@freebsd.org, freebsd-net@freebsd.org Subject: Re: ipv6 connection hash function wanted ... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 14 Nov 2006 16:36:35 -0000 On Tue, 14 Nov 2006, Max Laier wrote: > this one is something for people who know their math. > > Input: 2x128bit of address (lower ~80bit selectable by user) and 2x16bit > of ports (more or less selectable by user). Note that the "flow_id" is > not useable as several broken stack implementations do not set it > consistently - and it is user settable as well. > Output: "int" hash value - by default we use the lower 8bit of it. > > Problems: Most of the input can be selected by a user meaning it is easy > to produce collisions. For legal connections, the lower 64bit are the > one with the highest entropy - in fact the upper 64bit might be the same > for many connections coming from/going to the same subnet. This function > will be used for every packet that is passed to a dynamic IPFW rule, so > efficiency is a concern. > > Any ideas? Any papers that deal with this problem? > > ref: sys/netinet/ip_fw2.c::hash_packet6 If you are worried about users controlling which values their packets hash to you might want to look at universal hashing. People who are worried about algorithmic denial of service attacks face similar problems. A good place to start would probably be: http://www.cs.rice.edu/~scrosby/hash Paul Twohey twohey@cs From owner-freebsd-net@FreeBSD.ORG Tue Nov 14 17:23:46 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 9119016A403; Tue, 14 Nov 2006 17:23:46 +0000 (UTC) (envelope-from randy@psg.com) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 26AE043D49; Tue, 14 Nov 2006 17:23:46 +0000 (GMT) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by rip.psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1Gk20f-0002rb-8r; Tue, 14 Nov 2006 17:23:45 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by roam.psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1Gk1wY-0001KJ-O2; Tue, 14 Nov 2006 07:19:30 -1000 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17753.64161.965166.601002@roam.psg.com> Date: Tue, 14 Nov 2006 07:19:29 -1000 To: FreeBSD Current , freebsd-net@freebsd.org References: <17752.41644.706579.902238@roam.psg.com> Cc: Subject: Re: fxp going quiescent in current X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 14 Nov 2006 17:23:46 -0000 > FreeBSD rip.psg.com 7.0-CURRENT FreeBSD 7.0-CURRENT #3: Sat Nov 11 19:18:23 GMT 2006 root@rip.psg.com:/usr/obj/usr/src/sys/RIP i386 > > and for the last four or five days, fxp0 goes dead. it shows up > and active, but no packets move. > > down/up does not help. only way out has been reboot. > > suggestions on how to debug? this is killing me. noc woke me up twice in night to reboot the sucker. any clues? randy From owner-freebsd-net@FreeBSD.ORG Tue Nov 14 17:24:36 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.ORG 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 A90C216A415 for ; Tue, 14 Nov 2006 17:24:36 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id AFB8B43D53 for ; Tue, 14 Nov 2006 17:24:35 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (cxinax@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id kAEHOSJ9044974; Tue, 14 Nov 2006 18:24:34 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id kAEHOST9044973; Tue, 14 Nov 2006 18:24:28 +0100 (CET) (envelope-from olli) Date: Tue, 14 Nov 2006 18:24:28 +0100 (CET) Message-Id: <200611141724.kAEHOST9044973@lurza.secnetix.de> From: Oliver Fromme To: freebsd-net@FreeBSD.ORG, max@love2party.net In-Reply-To: X-Newsgroups: list.freebsd-net User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (FreeBSD/4.11-STABLE (i386)) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Tue, 14 Nov 2006 18:24:34 +0100 (CET) Cc: Subject: Re: ipv6 connection hash function wanted ... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-net@FreeBSD.ORG, max@love2party.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2006 17:24:36 -0000 Max Laier wrote: > Input: 2x128bit of address (lower ~80bit selectable by user) and 2x16bit > of ports (more or less selectable by user). Note that the "flow_id" is > not useable as several broken stack implementations do not set it > consistently - and it is user settable as well. > Output: "int" hash value - by default we use the lower 8bit of it. > > Problems: Most of the input can be selected by a user meaning it is easy > to produce collisions. For legal connections, the lower 64bit are the > one with the highest entropy - in fact the upper 64bit might be the same > for many connections coming from/going to the same subnet. This function > will be used for every packet that is passed to a dynamic IPFW rule, so > efficiency is a concern. If you want to prevent users from intentionally producing collisions, then you need to use a cryptographically strong hash function, such as SHA1/SHA256 which give 160 and 256 bits, respectively. If you only need a 32bit int, then simply pick the low 32bit of the SHA1/SHA256 and forget the rest. For normal uses I think MD5 might be sufficient, which is already implemented in the kernel (see MD5(9)). While MD5 hasn't actually been broken, some weaknesses haven been discovered that could be used to construct collisions under certain circumstances, but it's still far from easy and hasn't been proven for the generic case. If your hash doesn't have to be cryptographically secure, then a simple crc32 should be sufficient. This is much easier and faster to calculate. If even a single bit (any one) in the input changes, you will get a completely different crc32 value, so it should be suitable as a hash function. However, since it's not cryptographically strong, it _is_ possible to construct inputs that will produce collisions. Just my 2 cents. YMMV. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "C is quirky, flawed, and an enormous success." -- Dennis M. Ritchie. From owner-freebsd-net@FreeBSD.ORG Tue Nov 14 18:21:59 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 9C1E816A403; Tue, 14 Nov 2006 18:21:59 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id DA66F43D75; Tue, 14 Nov 2006 18:21:58 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 600DC46D8F; Tue, 14 Nov 2006 13:21:58 -0500 (EST) Date: Tue, 14 Nov 2006 18:21:58 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Randy Bush In-Reply-To: <17753.64161.965166.601002@roam.psg.com> Message-ID: <20061114181823.K87081@fledge.watson.org> References: <17752.41644.706579.902238@roam.psg.com> <17753.64161.965166.601002@roam.psg.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, FreeBSD Current Subject: Re: fxp going quiescent in current X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 14 Nov 2006 18:21:59 -0000 On Tue, 14 Nov 2006, Randy Bush wrote: >> FreeBSD rip.psg.com 7.0-CURRENT FreeBSD 7.0-CURRENT #3: Sat Nov 11 19:18:23 GMT 2006 root@rip.psg.com:/usr/obj/usr/src/sys/RIP i386 >> >> and for the last four or five days, fxp0 goes dead. it shows up >> and active, but no packets move. >> >> down/up does not help. only way out has been reboot. >> >> suggestions on how to debug? > > this is killing me. noc woke me up twice in night to reboot the sucker. > any clues? Do you have serial console access to the box? The usual questions read: (1) When it's "dead", do interrupts still fire for the interface when packets go near by? See vmstat -i. (2) Does the driver think the link is still negotiated? What are the interface flags set to? See ifconfig. (3) When you run tcpdump on the interace, does it see packets from the outside world? (4) If you ping out the interface, does tcpdump see packets? Do you get ENOBUFS? Have ping send at least 256 packets. Do you get errors? Send to the broadcast address so that arp doesn't need to be working to transmit. (5) What does netstat -m show? (6) Any unusual dmesg output? In particular, any mention of fxp state changes or watchdogs firing? (7) Does lowering the interface, waiting ten seconds, then raising it help? Notice that these are all much easier if you have a serial console. If not, you might want to do the above using cron and a temporary file followed by a reboot. :-) Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-net@FreeBSD.ORG Tue Nov 14 18:52:23 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 A9D2716A6A1 for ; Tue, 14 Nov 2006 18:52:23 +0000 (UTC) (envelope-from granica_raydom@rambler.ru) Received: from mxb.rambler.ru (mxb.rambler.ru [81.19.66.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 748AF43D49 for ; Tue, 14 Nov 2006 18:52:20 +0000 (GMT) (envelope-from granica_raydom@rambler.ru) Received: from rambler.ru (mail11.rambler.ru [81.19.71.13]) by mxb.rambler.ru (Postfix) with ESMTP id 5BA1F54F6A; Tue, 14 Nov 2006 21:52:19 +0300 (MSK) Received: from [85.141.114.63] (account granica_raydom@rambler.ru) by mail11.rambler.ru (CommuniGate Pro WebUser 4.2.10) with HTTP id 82525083; Tue, 14 Nov 2006 21:52:19 +0300 From: Andrew To: Max Laier X-Mailer: CommuniGate Pro WebUser Interface v.4.2.10 Date: Tue, 14 Nov 2006 21:52:19 +0300 Message-ID: In-Reply-To: <200611141709.26644.max@love2party.net> References: <200611141709.26644.max@love2party.net> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1251"; format="flowed" Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org Subject: Re: ipv6 connection hash function wanted ... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 14 Nov 2006 18:52:23 -0000 On Tue, 14 Nov 2006 17:09:20 +0100 Max Laier wrote: > Hello, > > this one is something for people who know their math. > > Input: 2x128bit of address (lower ~80bit selectable by user) and >2x16bit > of ports (more or less selectable by user). Note that the "flow_id" >is > not useable as several broken stack implementations do not set it > consistently - and it is user settable as well. > Output: "int" hash value - by default we use the lower 8bit of it. > > Problems: Most of the input can be selected by a user meaning it is >easy > to produce collisions. For legal connections, the lower 64bit are >the > one with the highest entropy - in fact the upper 64bit might be the >same > for many connections coming from/going to the same subnet. This >function > will be used for every packet that is passed to a dynamic IPFW rule, >so > efficiency is a concern. > > Any ideas? Any papers that deal with this problem? > > ref: sys/netinet/ip_fw2.c::hash_packet6 > May be the Rsync algorithm is suitable partially.. Here is the discription: http://samba.anu.edu.au/rsync/tech_report/ Andrew. From owner-freebsd-net@FreeBSD.ORG Tue Nov 14 19:09:32 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 EB21516A403; Tue, 14 Nov 2006 19:09:32 +0000 (UTC) (envelope-from dwmalone@maths.tcd.ie) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by mx1.FreeBSD.org (Postfix) with SMTP id 08EFB43D46; Tue, 14 Nov 2006 19:09:31 +0000 (GMT) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie ([134.226.81.10] helo=walton.maths.tcd.ie) by salmon.maths.tcd.ie with SMTP id ; 14 Nov 2006 19:09:30 +0000 (GMT) Date: Tue, 14 Nov 2006 19:09:30 +0000 From: David Malone To: Max Laier Message-ID: <20061114190930.GA23096@walton.maths.tcd.ie> References: <200611141709.26644.max@love2party.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200611141709.26644.max@love2party.net> User-Agent: Mutt/1.5.6i Sender: dwmalone@maths.tcd.ie Cc: freebsd-hackers@freebsd.org, freebsd-net@freebsd.org Subject: Re: ipv6 connection hash function wanted ... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 14 Nov 2006 19:09:33 -0000 On Tue, Nov 14, 2006 at 05:09:20PM +0100, Max Laier wrote: > Any ideas? Any papers that deal with this problem? Assuming you don't want to use one of the standard cryptographic ones (which I can imagine being a bit slow for something done per-packet), then one option might be to use a simpler hash that is keyed. Choose the key at boot/module load time and make it hard to produce collisions unless you know the key. David. From owner-freebsd-net@FreeBSD.ORG Tue Nov 14 19:21:23 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 A568516A55D; Tue, 14 Nov 2006 19:21:23 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.183]) by mx1.FreeBSD.org (Postfix) with ESMTP id 221EE43D72; Tue, 14 Nov 2006 19:21:02 +0000 (GMT) (envelope-from max@love2party.net) Received: from [88.66.1.82] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu1) with ESMTP (Nemesis), id 0MKwpI-1Gk3q21VMO-0000gD; Tue, 14 Nov 2006 20:20:54 +0100 From: Max Laier Organization: FreeBSD To: David Malone Date: Tue, 14 Nov 2006 20:20:47 +0100 User-Agent: KMail/1.9.4 References: <200611141709.26644.max@love2party.net> <20061114190930.GA23096@walton.maths.tcd.ie> In-Reply-To: <20061114190930.GA23096@walton.maths.tcd.ie> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1347703.ze6erUDHTS"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200611142020.53178.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: freebsd-hackers@freebsd.org, freebsd-net@freebsd.org Subject: Re: ipv6 connection hash function wanted ... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 14 Nov 2006 19:21:23 -0000 --nextPart1347703.ze6erUDHTS Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 14 November 2006 20:09, David Malone wrote: > On Tue, Nov 14, 2006 at 05:09:20PM +0100, Max Laier wrote: > > Any ideas? Any papers that deal with this problem? > > Assuming you don't want to use one of the standard cryptographic > ones (which I can imagine being a bit slow for something done > per-packet), then one option might be to use a simpler hash that > is keyed. Choose the key at boot/module load time and make it hard > to produce collisions unless you know the key. That's exactly what I am looking for ... now I need someone[tm] - with=20 better Math-Knowledge than mine - to write such a thing down in a simple=20 formula :-) i.e. take those bits from there and there and XOR them with=20 your canary yada-yada-yada ... =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart1347703.ze6erUDHTS Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQBFWhcVXyyEoT62BG0RAjiKAJ9dSHkBUj3/uxRoU6aoJ3ZTJ0oF9ACfQXpp 7h8OmbXL25j6zXx34OEJYhU= =apir -----END PGP SIGNATURE----- --nextPart1347703.ze6erUDHTS-- From owner-freebsd-net@FreeBSD.ORG Tue Nov 14 23:43:41 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 68D8916A415; Tue, 14 Nov 2006 23:43:41 +0000 (UTC) (envelope-from randy@psg.com) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB48243D53; Tue, 14 Nov 2006 23:43:40 +0000 (GMT) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by rip.psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1Gk7wK-00056s-1u; Tue, 14 Nov 2006 23:43:40 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by roam.psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1Gk7pu-0001h2-BM; Tue, 14 Nov 2006 13:37:02 -1000 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17754.21277.210338.175055@roam.psg.com> Date: Tue, 14 Nov 2006 13:37:01 -1000 To: Robert Watson References: <17752.41644.706579.902238@roam.psg.com> <17753.64161.965166.601002@roam.psg.com> <20061114181823.K87081@fledge.watson.org> Cc: freebsd-net@freebsd.org, FreeBSD Current Subject: Re: fxp going quiescent in current X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 14 Nov 2006 23:43:41 -0000 Mike Tancsa suggested i try ifconfig fxp0 media 10baseT/UTP ifconfig fxp0 media autoselect this worked! i will next reboot with in_fxp.c reverted to pre 2006.10.06. but first i did the suggested analysis, which follows. > (1) When it's "dead", do interrupts still fire for the interface when packets > go near by? See vmstat -i. nope > (2) Does the driver think the link is still negotiated? What are the > interface flags set to? See ifconfig. same as in first post on this whine # ifconfig fxp0 fxp0: flags=8843 mtu 1500 options=8 inet 147.28.0.39 netmask 0xffffff00 broadcast 147.28.0.255 inet 147.28.0.40 netmask 0xffffffff broadcast 147.28.0.40 ether 00:30:48:51:c8:5e media: Ethernet 100baseTX status: active > (3) When you run tcpdump on the interace, does it see packets from the > outside world? nope. only this interface issuing arp requests etc. > (4) If you ping out the interface, does tcpdump see packets? Do you get > ENOBUFS? Have ping send at least 256 packets. Do you get errors? Send > to the broadcast address so that arp doesn't need to be working to > transmit. fun one as, when it is in this state, i have only serial access through the craft port. this machine is 4000km away in a rack. so i nohupped and backgrounded the pinger, and watched tcpdump. nohup.out showed zero response ping: sendto: Host is down ping: sendto: Host is down ping: sendto: Host is down PING 147.28.0.35 (147.28.0.35): 56 data bytes --- 147.28.0.35 ping statistics --- 325 packets transmitted, 0 packets received, 100.0% packet loss tcpdump showed only the arp requests 23:32:41.459630 arp who-has 147.28.0.35 tell 147.28.0.39 23:32:42.460575 arp who-has 147.28.0.35 tell 147.28.0.39 23:32:43.461486 arp who-has 147.28.0.35 tell 147.28.0.39 23:32:44.462426 arp who-has 147.28.0.35 tell 147.28.0.39 23:32:45.463347 arp who-has 147.28.0.35 tell 147.28.0.39 23:32:46.464279 arp who-has 147.28.0.35 tell 147.28.0.39 > (5) What does netstat -m show? # netstat -m 132/693/825 mbufs in use (current/cache/total) 128/262/390/17088 mbuf clusters in use (current/cache/total/max) 128/256 mbuf+clusters out of packet secondary zone in use (current/cache) 0/28/28/0 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/0 9k jumbo clusters in use (current/cache/total/max) 0/0/0/0 16k jumbo clusters in use (current/cache/total/max) 289K/809K/1098K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/22/4528 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 30 requests for I/O initiated by sendfile 0 calls to protocol drain routines > (6) Any unusual dmesg output? In particular, any mention of fxp state > changes or watchdogs firing? nope # dmesg | grep fxp fxp0: port 0x9800-0x983f mem 0xe2203000-0xe2203fff,0xe2100000-0xe21fffff irq 5 at device 6.0 on pci2 miibus0: on fxp0 fxp0: Ethernet address: 00:30:48:51:c8:5e fxp1: port 0x9c00-0x9c3f mem 0xe2201000-0xe2201fff,0xe2000000-0xe20fffff irq 12 at device 7.0 on pci2 miibus1: on fxp1 fxp1: Ethernet address: 00:30:48:51:c8:5f fxp0: link state changed to UP fxp0: promiscuous mode enabled fxp0: promiscuous mode disabled > (7) Does lowering the interface, waiting ten seconds, then raising it > help? nope > Notice that these are all much easier if you have a serial console. well, most of them are :). > If not, you might want to do the above using cron and a temporary file > followed by a reboot. :-) i hope to do better than that :) randy From owner-freebsd-net@FreeBSD.ORG Wed Nov 15 02:38:55 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 104B616A49E for ; Wed, 15 Nov 2006 02:38:55 +0000 (UTC) (envelope-from dimitar.peikov@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0DF6543D46 for ; Wed, 15 Nov 2006 02:38:52 +0000 (GMT) (envelope-from dimitar.peikov@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so29256uge for ; Tue, 14 Nov 2006 18:38:52 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=GGDbb1WDQLwsYtwfguMYTxsD2Aj2acrRZq9bIRIBaP7NxL+daJMzBjCVhOY1appVI3RLVQHeBqXhRrHV5mAA1AoOCzLwEcE3xloR+lglgF5k7SHvWTUDP63nc32O3zxPQFpOq/7w52fpuz5/GW/kLel8P6gOH7lIJ8NlStWu2kE= Received: by 10.78.128.15 with SMTP id a15mr1799487hud.1163558331826; Tue, 14 Nov 2006 18:38:51 -0800 (PST) Received: by 10.78.153.6 with HTTP; Tue, 14 Nov 2006 18:38:51 -0800 (PST) Message-ID: <63c6c3f90611141838s4e860ab1qbd3ca7f848de31c0@mail.gmail.com> Date: Wed, 15 Nov 2006 04:38:51 +0200 From: "Dimitar Peikov" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: PPP using PPPoE failure X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 15 Nov 2006 02:38:55 -0000 Hello I'm just playing with 6.2-BETA3 and discovered something odd. I've setup my PPPoE connection to my ISP (it is working OK). The problem I observed appears while PPPoE connection is active I want to exit from PPP program. Then my PPP connection is closed, but I'm not able to open another session via tun0 adapter until restart. Also ppp process hangs (I guess it is blocked while try to open tun0 interface) - I waited for completion about 1min and didn't get it. Message that appears in ppp.log is : <<< Phase: Using interface: tun0 Phase: deflink: Created in closed state <<< Hope that this will help. -- --- Dimitar Peikov From owner-freebsd-net@FreeBSD.ORG Wed Nov 15 09:20:12 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 2D41616A403 for ; Wed, 15 Nov 2006 09:20:12 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id B3D4643D64 for ; Wed, 15 Nov 2006 09:20:11 +0000 (GMT) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (localhost [127.0.0.1]) by transport.cksoft.de (Postfix) with ESMTP id 8B6AA1FF903; Wed, 15 Nov 2006 10:20:10 +0100 (CET) Received: by transport.cksoft.de (Postfix, from userid 66) id C9A8E1FFD35; Wed, 15 Nov 2006 10:20:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 962FB444A01; Wed, 15 Nov 2006 09:15:20 +0000 (UTC) Date: Wed, 15 Nov 2006 09:15:20 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Dimitar Peikov In-Reply-To: <63c6c3f90611141838s4e860ab1qbd3ca7f848de31c0@mail.gmail.com> Message-ID: <20061115091251.B18512@maildrop.int.zabbadoz.net> References: <63c6c3f90611141838s4e860ab1qbd3ca7f848de31c0@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de Cc: freebsd-net@freebsd.org Subject: Re: PPP using PPPoE failure X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 15 Nov 2006 09:20:12 -0000 On Wed, 15 Nov 2006, Dimitar Peikov wrote: > Hello > > I'm just playing with 6.2-BETA3 and discovered something odd. > I've setup my PPPoE connection to my ISP (it is working OK). > The problem I observed appears while PPPoE connection is active I want > to exit from PPP program. Then my PPP connection is closed, but I'm > not able to open another session via tun0 adapter until restart. Also > ppp process hangs (I guess it is blocked while try to open tun0 > interface) - I waited for completion about 1min and didn't get it. > > Message that appears in ppp.log is : > <<< > Phase: Using interface: tun0 > Phase: deflink: Created in closed state > <<< > > Hope that this will help. can you enable Log All in ppp.conf and see what it says then? Also a ngctl list and you checking tcpdump if you can see PPPoE PADI PADO PAD PADR PADS PADT packets would be helpful. Do that on the interface pppoe is configure for (not tun0). -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT From owner-freebsd-net@FreeBSD.ORG Wed Nov 15 11:54:18 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.ORG 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 1018B16A403 for ; Wed, 15 Nov 2006 11:54:18 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A90943D62 for ; Wed, 15 Nov 2006 11:54:17 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (sdybkv@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id kAFBsAMj091996 for ; Wed, 15 Nov 2006 12:54:16 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id kAFBsAXT091995; Wed, 15 Nov 2006 12:54:10 +0100 (CET) (envelope-from olli) Date: Wed, 15 Nov 2006 12:54:10 +0100 (CET) Message-Id: <200611151154.kAFBsAXT091995@lurza.secnetix.de> From: Oliver Fromme To: freebsd-net@FreeBSD.ORG In-Reply-To: <200611142020.53178.max@love2party.net> X-Newsgroups: list.freebsd-net User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (FreeBSD/4.11-STABLE (i386)) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Wed, 15 Nov 2006 12:54:16 +0100 (CET) Cc: Subject: Re: ipv6 connection hash function wanted ... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-net@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG, max@love2party.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2006 11:54:18 -0000 Max Laier wrote: > David Malone wrote: > > Assuming you don't want to use one of the standard cryptographic > > ones (which I can imagine being a bit slow for something done > > per-packet), then one option might be to use a simpler hash that > > is keyed. Choose the key at boot/module load time and make it hard > > to produce collisions unless you know the key. > > That's exactly what I am looking for ... now I need someone[tm] - with > better Math-Knowledge than mine - to write such a thing down in a simple > formula :-) i.e. take those bits from there and there and XOR them with > your canary yada-yada-yada ... In that case, simply use crc32 (available from libkern.h) and xor with a random key generated at boot time. crc32 is fast to calculate and has the properties that you need. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "Perl will consistently give you what you want, unless what you want is consistency." -- Larry Wall From owner-freebsd-net@FreeBSD.ORG Wed Nov 15 13:01:36 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.ORG 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 A28E516A47B; Wed, 15 Nov 2006 13:01:36 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id EE0EF43D6E; Wed, 15 Nov 2006 13:01:22 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (uzyroz@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id kAFD1GmS095075; Wed, 15 Nov 2006 14:01:21 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id kAFD1G9d095074; Wed, 15 Nov 2006 14:01:16 +0100 (CET) (envelope-from olli) Date: Wed, 15 Nov 2006 14:01:16 +0100 (CET) Message-Id: <200611151301.kAFD1G9d095074@lurza.secnetix.de> From: Oliver Fromme To: freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG, max@love2party.net In-Reply-To: <200611151126.kAFBQSQr090632@lurza.secnetix.de> X-Newsgroups: list.freebsd-hackers User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (FreeBSD/4.11-STABLE (i386)) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Wed, 15 Nov 2006 14:01:21 +0100 (CET) Cc: Subject: Re: ipv6 connection hash function wanted ... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG, max@love2party.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2006 13:01:36 -0000 Oliver Fromme wrote: > Max Laier wrote: > > David Malone wrote: > > > Assuming you don't want to use one of the standard cryptographic > > > ones (which I can imagine being a bit slow for something done > > > per-packet), then one option might be to use a simpler hash that > > > is keyed. Choose the key at boot/module load time and make it hard > > > to produce collisions unless you know the key. > > > > That's exactly what I am looking for ... now I need someone[tm] - with > > better Math-Knowledge than mine - to write such a thing down in a simple > > formula :-) i.e. take those bits from there and there and XOR them with > > your canary yada-yada-yada ... > > In that case, simply use crc32 (available from libkern.h) > and xor with a random key generated at boot time. crc32 > is fast to calculate and has the properties that you need. Uhm, sorry, after reading that sentence again and thinking about it, it seems to be misleading. You have to xor with a random key _first_, and _then_ calculate the crc32 value. If you did it the other way, the random key would not prevent from collisions at all, because: same_crc ^ same_key == same_hash. ;-) Suppose a malicious user is able to create two different sets of connections parameters (P1 and P2) which have the same CRC32 value (without using a key): P1 != P2 crc32(P1) == crc32(P2) If you xor (or add) the random key K to the parameters, it will change the outcome of the crc32 calculation in different ways: crc32(P1 ^ K) != crc32(P2 ^ K) Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "I made up the term 'object-oriented', and I can tell you I didn't have C++ in mind." -- Alan Kay, OOPSLA '97 From owner-freebsd-net@FreeBSD.ORG Wed Nov 15 14:39:06 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 8524416A492 for ; Wed, 15 Nov 2006 14:39:06 +0000 (UTC) (envelope-from miroslav@svishtov.net) Received: from mail.svishtov.net (mail.svishtov.net [85.217.192.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1D57143D53 for ; Wed, 15 Nov 2006 14:38:57 +0000 (GMT) (envelope-from miroslav@svishtov.net) X-Spam-Status: No, hits=4.8 required=7.5 tests=AWL: -1.086,BAYES_99: 4.07,HTML_30_40: 0.437, HTML_MESSAGE: 0.001,RCVD_NUMERIC_HELO: 1.348 X-Spam-Level: **** Received: from 85.217.217.217 ([85.217.217.217]) by mail.svishtov.net (Kerio MailServer 6.1.1) for miroslav@svishtov.net; Wed, 15 Nov 2006 15:46:56 +0200 From: Miroslav Slavkov To: freebsd-net@freebsd.org Message-ID: <20061115134656.8dfe91de@mail.svishtov.net> Date: Wed, 15 Nov 2006 15:46:56 +0200 X-Mailer: Kerio MailServer 6.1.1 WebMail X-User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: em driver - strange behavior X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 15 Nov 2006 14:39:06 -0000 Hi. I've posted some test with the latest em driver in the previous thread "= Proposed 6.2 em RELEASE patch"... It's working fine. Now i see some strange behavior. Machine is Dual Intel Xeon 5110, with = SuperMicro X7-DBE mainboard. It has dual port integrated Intel PRO/1000 = EB lan card, one Intel 82542 Gigabit Ethernet Controller, and one Intel = PRO/1000 PT. The problem is the Intel PRO/1000 PT card. All other cards are in use (i= n production mode), only this card is down and not used right now, but i= t's generating more interrupts than any other card. em3: flags=3D8802 mtu 1500 options=3Db ether 00:15:17:0e:10:90 media: Ethernet autoselect status: no carrier output from systat -vm (interrupts/irq/interface): 14235 16: em3 6214 18: em0 914 19: em1 13613 24: em2 currently it has around 200Mbit/s total bandwidth on the other cards system is: FreeBSD 6.2-PRERELEASE #1: Tue Nov 14 17:24:17 EET 2006 amd64 EM=5FINTR=5FFAST is defined in em driver no polling Any clues=3F =5F=5F Miroslav From owner-freebsd-net@FreeBSD.ORG Wed Nov 15 16:24:33 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 9E31616A407 for ; Wed, 15 Nov 2006 16:24:33 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED5EA43D58 for ; Wed, 15 Nov 2006 16:24:32 +0000 (GMT) (envelope-from jfvogel@gmail.com) Received: by nz-out-0102.google.com with SMTP id i11so78119nzh for ; Wed, 15 Nov 2006 08:24:32 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=sR0023iOczWaBmbkVwARL+rQcJSxOivRHBinLey1RbOMZlqwLluv7TA3z0eMC3bNcGlA+S6+9ymNFdq3xFIA6r6AdCdTZ1t6xbdMx6T5YwqcSN/ILT2S2wytNoUzQUWykG1h7RQCEENQPTHPqTTOfxW5ah/Fy1pAAk62ICtfNr4= Received: by 10.35.89.10 with SMTP id r10mr3506100pyl.1163607868695; Wed, 15 Nov 2006 08:24:28 -0800 (PST) Received: by 10.35.118.6 with HTTP; Wed, 15 Nov 2006 08:24:28 -0800 (PST) Message-ID: <2a41acea0611150824q29630455wdbeae231e902456e@mail.gmail.com> Date: Wed, 15 Nov 2006 08:24:28 -0800 From: "Jack Vogel" To: "Miroslav Slavkov" In-Reply-To: <20061115134656.8dfe91de@mail.svishtov.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20061115134656.8dfe91de@mail.svishtov.net> Cc: freebsd-net@freebsd.org Subject: Re: em driver - strange behavior X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 15 Nov 2006 16:24:33 -0000 On 11/15/06, Miroslav Slavkov wrote: > Hi. > I've posted some test with the latest em driver in the previous thread "Proposed 6.2 em RELEASE patch"... > It's working fine. > Now i see some strange behavior. Machine is Dual Intel Xeon 5110, with SuperMicro X7-DBE mainboard. It has dual port integrated Intel PRO/1000 EB lan card, one Intel 82542 Gigabit Ethernet Controller, and one Intel PRO/1000 PT. > The problem is the Intel PRO/1000 PT card. All other cards are in use (in production mode), only this card is down and not used right now, but it's generating more interrupts than any other card. > > em3: flags=8802 mtu 1500 > options=b > ether 00:15:17:0e:10:90 > media: Ethernet autoselect > status: no carrier > > > output from systat -vm (interrupts/irq/interface): > 14235 16: em3 > 6214 18: em0 > 914 19: em1 > 13613 24: em2 > > currently it has around 200Mbit/s total bandwidth on the other cards > > system is: FreeBSD 6.2-PRERELEASE #1: Tue Nov 14 17:24:17 EET 2006 amd64 > EM_INTR_FAST is defined in em driver > no polling > > Any clues? Your description is a bit confusing, is this port ON the motherboard? If its not in use by the OS but it still shows interrupts I'm suspecting the management hardware maybe? Jack From owner-freebsd-net@FreeBSD.ORG Wed Nov 15 18:00:20 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 899CE16A417 for ; Wed, 15 Nov 2006 18:00:20 +0000 (UTC) (envelope-from miroslav@svishtov.net) Received: from mail.svishtov.net (mail.svishtov.net [85.217.192.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8EBDE43D5A for ; Wed, 15 Nov 2006 18:00:18 +0000 (GMT) (envelope-from miroslav@svishtov.net) X-Spam-Status: No, hits=4.6 required=7.5 tests=AWL: -0.891,BAYES_99: 4.07,HTML_40_50: 0.052, HTML_MESSAGE: 0.001,RCVD_NUMERIC_HELO: 1.348 X-Spam-Level: **** Received: from 85.217.192.21 ([85.217.192.21]) by mail.svishtov.net (Kerio MailServer 6.1.1) for miroslav@svishtov.net; Wed, 15 Nov 2006 19:08:16 +0200 From: Miroslav Slavkov To: Jack Vogel In-Reply-To: <2a41acea0611150824q29630455wdbeae231e902456e@mail.gmail.com> Message-ID: <20061115170816.4753c097@mail.svishtov.net> Date: Wed, 15 Nov 2006 19:08:16 +0200 X-Mailer: Kerio MailServer 6.1.1 WebMail X-User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: em driver - strange behavior X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 15 Nov 2006 18:00:20 -0000 The Card is external Intel Pro/1000 PT Server Adapter on PCI-Express slo= t. =20 =5F=5F=5F=5F=5F =20 From: Jack Vogel [mailto:jfvogel@gmail.com] To: Miroslav Slavkov [mailto:miroslav@svishtov.net] Cc: freebsd-net@freebsd.org Sent: Wed, 15 Nov 2006 18:24:28 +0200 Subject: Re: em driver - strange behavior On 11/15/06, Miroslav Slavkov wrote: > Hi. > I've posted some test with the latest em driver in the previous thread= "Proposed 6.2 em RELEASE patch"... > It's working fine. > Now i see some strange behavior. Machine is Dual Intel Xeon 5110, wit= h SuperMicro X7-DBE mainboard. It has dual port integrated Intel PRO/10= 00 EB lan card, one Intel 82542 Gigabit Ethernet Controller, and one In= tel PRO/1000 PT. > The problem is the Intel PRO/1000 PT card. All other cards are in use= (in production mode), only this card is down and not used right now, b= ut it's generating more interrupts than any other card. > > em3: flags=3D8802 mtu 1500 > options=3Db > ether 00:15:17:0e:10:90 > media: Ethernet autoselect > status: no carrier > > > output from systat -vm (interrupts/irq/interface): > 14235 16: em3 > 6214 18: em0 > 914 19: em1 > 13613 24: em2 > > currently it has around 200Mbit/s total bandwidth on the other cards > > system is: FreeBSD 6.2-PRERELEASE #1: Tue Nov 14 17:24:17 EET 2006 amd= 64 > EM=5FINTR=5FFAST is defined in em driver > no polling > > Any clues=3F Your description is a bit confusing, is this port ON the motherboard=3F If its not in use by the OS but it still shows interrupts I'm suspecting the management hardware maybe=3F Jack =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F 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 From owner-freebsd-net@FreeBSD.ORG Wed Nov 15 18:04:10 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 1F98116A403; Wed, 15 Nov 2006 18:04:10 +0000 (UTC) (envelope-from randy@psg.com) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C70043D5D; Wed, 15 Nov 2006 18:04:09 +0000 (GMT) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by rip.psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GkP7I-000MTQ-6o; Wed, 15 Nov 2006 18:04:08 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by roam.psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GkP7E-000187-BK; Wed, 15 Nov 2006 08:04:04 -1000 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17755.22163.457287.603699@roam.psg.com> Date: Wed, 15 Nov 2006 08:04:03 -1000 To: Robert Watson References: <17752.41644.706579.902238@roam.psg.com> <17753.64161.965166.601002@roam.psg.com> <20061114181823.K87081@fledge.watson.org> <17754.21277.210338.175055@roam.psg.com> Cc: freebsd-net@freebsd.org, FreeBSD Current Subject: Re: fxp going quiescent in current X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 15 Nov 2006 18:04:10 -0000 > Mike Tancsa suggested i try > ifconfig fxp0 media 10baseT/UTP > ifconfig fxp0 media autoselect > this worked! > > i will next reboot with in_fxp.c reverted to pre 2006.10.06. and this also worked. i.e. there is poison in the if_fxp.c update of 2006.10.06 randy From owner-freebsd-net@FreeBSD.ORG Wed Nov 15 18:25:02 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 ED1C816A513 for ; Wed, 15 Nov 2006 18:25:02 +0000 (UTC) (envelope-from citrin@citrin.ru) Received: from mail.classis.ru (classis.ru [213.248.60.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB6E343D53 for ; Wed, 15 Nov 2006 18:25:01 +0000 (GMT) (envelope-from citrin@citrin.ru) Received: from citrin (unknown [81.19.65.97]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: citrin.citrin.ru) by mail.classis.ru (Postfix) with ESMTP id B41C8122A5F9 for ; Wed, 15 Nov 2006 21:24:58 +0300 (MSK) Date: Wed, 15 Nov 2006 21:24:51 +0300 From: Anton Yuzhaninov X-Mailer: The Bat! (v3.62.14) Professional Organization: Rambler X-Priority: 3 (Normal) Message-ID: <839684120.20061115212451@citrin.ru> To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: rl nic don't work on Acer Aspire 3610 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 15 Nov 2006 18:25:03 -0000 Hello. rl from Acer Aspire 3610 don't work under FreeBSD 6.2-BETA3 ifconfig show no carrier. Manual "media 100baseTX" don't help. $ grep rl0 dmesg.boot pcib1: rl0 requested I/O range 0x3000-0x30ff: in range pcib1: rl0 requested I/O range 0x3000-0x30ff: in range rl0: port 0x3000-0x30ff mem 0xb0100000-0xb01000ff irq 20 at device 7.0 on pci6 pcib1: rl0 requested I/O range 0x3000-0x30ff: in range miibus0: on rl0 rl0: bpf attached rl0: Ethernet address: 00:0a:e4:e4:8c:fa rl0: [MPSAFE] rl0: watchdog timeout rl0: watchdog timeout rl0: watchdog timeout rl0: watchdog timeout rl0@pci6:7:0: class=0x020000 card=0x006a1025 chip=0x813910ec rev=0x10 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RT8139 (A/B/C/810x/813x/C+) Fast Ethernet Adapter' class = network subclass = ethernet When system boot with acpi I see many errors like: acpi_ec0: EcRead: Failed waiting for EC to send data. ACPI-0501: *** Error: Handler for [EmbeddedControl] returned AE_NO_HARDWARE_RESPONSE ACPI-1304: *** Error: Method execution failed [\_TZ_.TZS0._TMP] (Node 0xc43b6da0), AE_NO_HARDWARE_RESPONSE acpi_tz0: error fetching current temperature -- AE_NO_HARDWARE_RESPONSE acpi_ec0: EcRead: Failed waiting for EC to send data. ACPI-0501: *** Error: Handler for [EmbeddedControl] returned AE_NO_HARDWARE_RESPONSE ACPI-1304: *** Error: Method execution failed [\_TZ_.TZS0._TMP] (Node 0xc43b6da0), AE_NO_HARDWARE_RESPONSE acpi_tz0: error fetching current temperature -- AE_NO_HARDWARE_RESPONSE I try to boot without acpi, but it also don't work. How I can debug this problem? Under WinXP this network card work fine. dmesg output available here: http://citrin.ru/tmp/aspire3610/ -- WBR, Anton Yuzhaninov From owner-freebsd-net@FreeBSD.ORG Wed Nov 15 20:23:04 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 2C3A116A403 for ; Wed, 15 Nov 2006 20:23:04 +0000 (UTC) (envelope-from dimitar.peikov@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id B5C5B43D62 for ; Wed, 15 Nov 2006 20:22:56 +0000 (GMT) (envelope-from dimitar.peikov@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so236933uge for ; Wed, 15 Nov 2006 12:22:55 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:to:subject:date:user-agent:references:in-reply-to:cc:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:from; b=PvU0/KYahbvnvvImM30e5d3UoBkN0banpPsCyULdSCtLbHEIPfjnw/tKLxmT6kQSJJBomaLsIB001hUQO25n1taobOmXPWf1775cAeHLxlaaKMlh76X8oAzw5CzKnRknZOF28WkbpKEXFcJ9B/fBvWeFIEJknMHPrqyiAcl8NI4= Received: by 10.67.26.7 with SMTP id d7mr3606178ugj.1163622175137; Wed, 15 Nov 2006 12:22:55 -0800 (PST) Received: from mmdn-121.mmdn.biz ( [195.34.103.121]) by mx.google.com with ESMTP id s7sm1417990uge.2006.11.15.12.22.54; Wed, 15 Nov 2006 12:22:54 -0800 (PST) To: "Bjoern A. Zeeb" Date: Wed, 15 Nov 2006 22:24:49 +0200 User-Agent: KMail/1.9.4 References: <63c6c3f90611141838s4e860ab1qbd3ca7f848de31c0@mail.gmail.com> <20061115091251.B18512@maildrop.int.zabbadoz.net> In-Reply-To: <20061115091251.B18512@maildrop.int.zabbadoz.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200611152224.49679.Dimitar.Peikov@gmail.com> From: Dimitar Peikov Cc: freebsd-net@freebsd.org Subject: Re: PPP using PPPoE failure X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 15 Nov 2006 20:23:04 -0000 On Wednesday 15 November 2006 11:15, you wrote: > On Wed, 15 Nov 2006, Dimitar Peikov wrote: > > Hello > > > > I'm just playing with 6.2-BETA3 and discovered something odd. > > I've setup my PPPoE connection to my ISP (it is working OK). > > The problem I observed appears while PPPoE connection is active I want > > to exit from PPP program. Then my PPP connection is closed, but I'm > > not able to open another session via tun0 adapter until restart. Also > > ppp process hangs (I guess it is blocked while try to open tun0 > > interface) - I waited for completion about 1min and didn't get it. > > > > Message that appears in ppp.log is : > > <<< > > Phase: Using interface: tun0 > > Phase: deflink: Created in closed state > > <<< > > > > Hope that this will help. > > can you enable > Log All > in ppp.conf and see what it says then? > > Also a ngctl list and you checking tcpdump if you can see PPPoE PADI > PADO PAD PADR PADS PADT packets would be helpful. Do that on the > interface pppoe is configure for (not tun0). Thank you for the feedback, but now I'm not able to reproduce it. So far I'll try to get this error again and when I catch it, I'll send requested information. I'm continuing to try to reproduce this issue. --- Dimitar Peikov from Gmail From owner-freebsd-net@FreeBSD.ORG Wed Nov 15 20:44:43 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 9DCB716A40F for ; Wed, 15 Nov 2006 20:44:43 +0000 (UTC) (envelope-from ml.diespammer@netfence.it) Received: from parrot.aev.net (parrot.aev.net [212.31.247.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id CC71243D6E for ; Wed, 15 Nov 2006 20:44:14 +0000 (GMT) (envelope-from ml.diespammer@netfence.it) Received: from soth.ventu (adsl-ull-214-242.51-151.net24.it [151.51.242.214]) (authenticated bits=128) by parrot.aev.net (8.13.8/8.13.6) with ESMTP id kAFKrino094527 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 15 Nov 2006 21:53:51 +0100 (CET) (envelope-from ml.diespammer@netfence.it) Received: from [10.1.2.18] (alamar.ventu [10.1.2.18]) by soth.ventu (8.13.8/8.13.3) with ESMTP id kAFKi0DF045708 for ; Wed, 15 Nov 2006 21:44:00 +0100 (CET) (envelope-from ml.diespammer@netfence.it) Message-ID: <455B7C11.3020101@netfence.it> Date: Wed, 15 Nov 2006 21:44:01 +0100 From: Andrea Venturoli User-Agent: Thunderbird 1.5.0.7 (X11/20061025) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 212.31.247.179 Subject: watchguard VPN X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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: Wed, 15 Nov 2006 20:44:43 -0000 Hi. I have a Windows machine using a watchguard VPN client and no control over the other end. Is there anything I can do in FreeBSD to replace that? Does anyone know what protocols it uses? bye & Thanks av. From owner-freebsd-net@FreeBSD.ORG Wed Nov 15 22:11:12 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 7605116A494 for ; Wed, 15 Nov 2006 22:11:12 +0000 (UTC) (envelope-from landonf@threerings.net) Received: from smtp.earth.threerings.net (mail.threerings.net [64.127.109.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id D3DE343D49 for ; Wed, 15 Nov 2006 22:10:43 +0000 (GMT) (envelope-from landonf@threerings.net) Received: from [192.168.54.11] (timor.sea.earth.threerings.net [192.168.54.11]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.earth.threerings.net (Postfix) with ESMTP id 5B5CB6245 for ; Wed, 15 Nov 2006 14:10:43 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-19-637845215" Message-Id: <493C2C49-C7A4-4CF6-BF03-556967FFFD60@threerings.net> Content-Transfer-Encoding: 7bit From: Landon Fuller Date: Wed, 15 Nov 2006 14:10:38 -0800 To: freebsd-net@freebsd.org X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.752.3) Subject: Re: [patch] tun(4) and tap(4) if_clone support. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 15 Nov 2006 22:11:12 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-19-637845215 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Nov 7, 2006, at 15:37, Landon Fuller wrote: > Nick Barkas (snb@threerings.net) and I have added interface cloning > support to the tun(4) and tap(4) drivers. > > We maintained backwards-compatible support for devfs cloning, which > is now disabled by default -- it can be re-enabled via a sysctl. > Interfaces that are created via devfs cloning may still be removed > via ifconfig destroy. > > The latest patch is available here > http://www.opendarwin.org/~landonf/code/patch-tuntap_ifclone > > I've submitted kern/105228 with the patch, and I'd be most > appreciative of comments/suggestions. Anyone willing to review and commit? -landonf --Apple-Mail-19-637845215 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFFW5BilplZCE/15mMRAtjiAJ4oHqIZB52dkQH1uojWEQIrEQ2wVACfXGhY hTRZmo1+m5bPlVw8svjp+Ms= =ckXt -----END PGP SIGNATURE----- --Apple-Mail-19-637845215-- From owner-freebsd-net@FreeBSD.ORG Thu Nov 16 08:52:35 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 A681116A415; Thu, 16 Nov 2006 08:52:35 +0000 (UTC) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE70843D5D; Thu, 16 Nov 2006 08:52:34 +0000 (GMT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from impact.jinmei.org (unknown [2001:200:1b1:1010:20e:7bff:fedd:fe03]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 84D9515218; Thu, 16 Nov 2006 17:52:32 +0900 (JST) Date: Thu, 16 Nov 2006 17:52:32 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Max Laier In-Reply-To: <200611142020.53178.max@love2party.net> References: <200611141709.26644.max@love2party.net> <20061114190930.GA23096@walton.maths.tcd.ie> <200611142020.53178.max@love2party.net> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: David Malone , freebsd-hackers@freebsd.org, freebsd-net@freebsd.org Subject: Re: ipv6 connection hash function wanted ... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Nov 2006 08:52:35 -0000 >>>>> On Tue, 14 Nov 2006 20:20:47 +0100, >>>>> Max Laier said: >> > Any ideas? Any papers that deal with this problem? >> >> Assuming you don't want to use one of the standard cryptographic >> ones (which I can imagine being a bit slow for something done >> per-packet), then one option might be to use a simpler hash that >> is keyed. Choose the key at boot/module load time and make it hard >> to produce collisions unless you know the key. > That's exactly what I am looking for ... now I need someone[tm] - with > better Math-Knowledge than mine - to write such a thing down in a simple > formula :-) i.e. take those bits from there and there and XOR them with > your canary yada-yada-yada ... If you want something whose behavior is mathematically guaranteed, I'd recommend universal hashing as already suggested in this thread. One example implementation is given below, assuming the hash key is source and destination IPv6 addresses and transport layer ports(*). As shown in the implementation, it's pretty simple and should run reasonably fast. Also, as long as the random values are reasonably unpredictable, the expected probability of producing the same hash value for arbitrarily-chosen two different keys is 1/65537. In general, for any prime number p as the value of LARGE_PRIME, this probability is 1/p (so if 65537 is too large, we can use a smaller number, e.g., 1009, depending on the desired balance between collision risk and memory footprint for hash buckets). (*)Technically, using in6_addr to represent an IPv6 address may not be enough; we may want to take into account zone indices (sin6_scope_id) as part of hash keys. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp #define HASHKEYLEN 38 /* sizeof(in6_addr) * 2 + sizeof(in_port_t) * 2 */ #define LARGE_PRIME 65537 /* * This should be filled with unpredictable random values between 0 * and LARGE_PRIME-1 at startup time. */ u_int32_t random_parameters[HASHKEYLEN]; u_int32_t hash(struct in6_addr *saddr, struct in6_addr *daddr, in_port_t sport, in_port_t dport) { int i, j = 0; u_int32_t accumulated = 0; u_char *cp; for (i = 0; i < sizeof(*saddr); i++) accumulated += saddr->s6_addr[i] * random_parameters[j++]; for (i = 0; i < sizeof(*saddr); i++) accumulated += daddr->s6_addr[i] * random_parameters[j++]; cp = (u_char *)&sport; for (i = 0; i < sizeof(sport); i++) accumulated += cp[i] * random_parameters[j++]; cp = (u_char *)&dport; for (i = 0; i < sizeof(dport); i++) accumulated += cp[i] * random_parameters[j++]; return (accumulated % LARGE_PRIME); } From owner-freebsd-net@FreeBSD.ORG Thu Nov 16 16:15:10 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 C759B16A47B for ; Thu, 16 Nov 2006 16:15:10 +0000 (UTC) (envelope-from jgordeev@dir.bg) Received: from dir.bg (mail.dir.bg [194.145.63.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id E3E0443D73 for ; Thu, 16 Nov 2006 16:15:07 +0000 (GMT) (envelope-from jgordeev@dir.bg) Received: from [87.118.128.195] (account jgordeev HELO [10.102.9.40]) by dir.bg (CommuniGate Pro SMTP 4.2.10) with ESMTP-TLS id 26088137 for freebsd-net@freebsd.org; Thu, 16 Nov 2006 18:19:09 +0200 Message-ID: <455C8FC0.4050901@dir.bg> Date: Thu, 16 Nov 2006 18:20:16 +0200 From: Jordan Gordeev User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060627 X-Accept-Language: bg, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: patch for arpwatch to ignore CARP-generated ARP replies X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Nov 2006 16:15:10 -0000 Problem description: CARP answers ARP requests for a virtual IP with ARP replies that have the MAC of the physical interface in the Ethernet header and the virtual MAC in the contained ARP message. These strange ARP messages are logged by arpwatch as "ethernet mismatch". There's a patch below that causes arpwatch (version 2.1a15) to ignore ARP replies generated by CARP, instead of reporting "ethernet mismatch" via syslog. Please, share your opinions. --- arpwatch.c.old Wed Nov 15 19:39:16 2006 +++ arpwatch.c Wed Nov 15 19:51:26 2006 @@ -105,6 +105,9 @@ #define max(a,b) ((b)>(a)?(b):(a)) #endif +#define VRRP_PREFIX_LEN 5 +const unsigned char vrrp_prefix[VRRP_PREFIX_LEN] = { 0x00, 0x00, 0x5e, 0x00, 0x01 }; + char *prog; int can_checkpoint; @@ -391,6 +394,10 @@ return; } + /* Check for CARP-generated ARP replies and ignore them */ + if (MEMCMP(sha, vrrp_prefix, VRRP_PREFIX_LEN) == 0) { + /* do nothing */ + } else /* Double check ethernet addresses */ if (MEMCMP(sea, sha, 6) != 0) { dosyslog(LOG_INFO, "ethernet mismatch", sia, sea, sha); From owner-freebsd-net@FreeBSD.ORG Thu Nov 16 18:50:59 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 8C2E416A416 for ; Thu, 16 Nov 2006 18:50:59 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id A6FB843D5A for ; Thu, 16 Nov 2006 18:50:58 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 35801 invoked from network); 16 Nov 2006 18:43:14 -0000 Received: from dotat.atdotat.at (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 16 Nov 2006 18:43:14 -0000 Message-ID: <455CB311.8040301@freebsd.org> Date: Thu, 16 Nov 2006 19:50:57 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b) Gecko/20050217 MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Automatic TCP send socker buffer sizing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Nov 2006 18:50:59 -0000 This is a patch adding automatic TCP send socket buffer sizing. Normally the socket buffers are static (either derived from global defaults or set with setsockopt) and do not adapt to real network conditions. Two things happen: a) your socket buffers are too small and you can't reach the full potential of the network between both hosts; b) your socket buffers are too big and you waste a lot of kernel memory for data just sitting around. With automatic TCP send socket buffers we can start with a small buffer and quickly grow it in parallel with the TCP congestion window to match real network conditions. FreeBSD has a default 32K send socket buffer. This supports a maximal transfer rate of only slightly more than 2Mbit/s on a 100ms RTT trans- continental link. Or at 200ms just above 1Mbit/s. With TCP send buffer auto scaling and the default values below it supports 20Mbit/s at 100ms and 10Mbit/s at 200ms. That's an improvement of factor 10, or 1000%. New sysctl's are: net.inet.tcp.sndbuf_auto=1 (enabled) net.inet.tcp.sndbuf_inc=8192 (8K, step size) net.inet.tcp.sndbuf_max=262144 (256K, growth limit) The patch is available here: http://people.freebsd.org/~andre/tcp_auto_sndbuf-20061116.diff Any testers, especially with busy FTP servers, are very welcome. -- Andre From owner-freebsd-net@FreeBSD.ORG Thu Nov 16 21:16:26 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 62FA416A51F; Thu, 16 Nov 2006 21:16:26 +0000 (UTC) (envelope-from dwmalone@maths.tcd.ie) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by mx1.FreeBSD.org (Postfix) with SMTP id 50B2043D79; Thu, 16 Nov 2006 21:16:19 +0000 (GMT) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie ([134.226.81.10] helo=walton.maths.tcd.ie) by salmon.maths.tcd.ie with SMTP id ; 16 Nov 2006 21:16:18 +0000 (GMT) Date: Thu, 16 Nov 2006 21:16:17 +0000 From: David Malone To: "JINMEI Tatuya / ?$B?@L@C#:H" Message-ID: <20061116211617.GA86177@walton.maths.tcd.ie> References: <200611141709.26644.max@love2party.net> <20061114190930.GA23096@walton.maths.tcd.ie> <200611142020.53178.max@love2party.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i Sender: dwmalone@maths.tcd.ie Cc: Max Laier , freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: ipv6 connection hash function wanted ... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Nov 2006 21:16:26 -0000 On Thu, Nov 16, 2006 at 05:52:32PM +0900, JINMEI Tatuya / ?$B?@L@C#:H wrote: > If you want something whose behavior is mathematically guaranteed, I'd > recommend universal hashing as already suggested in this thread. Yep - I agree. I'll try and sort something out for Max - it may need some careful tweaks if it is to be symetric in src/dst ports and ips. David. From owner-freebsd-net@FreeBSD.ORG Thu Nov 16 22:35:02 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 8A9DF16A62B; Thu, 16 Nov 2006 22:35:02 +0000 (UTC) (envelope-from pp@pp.dyndns.biz) Received: from mxfep03.bredband.com (mxfep03.bredband.com [195.54.107.76]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0CBD843D76; Thu, 16 Nov 2006 22:34:54 +0000 (GMT) (envelope-from pp@pp.dyndns.biz) Received: from ironport2.bredband.com ([195.54.107.84] [195.54.107.84]) by mxfep03.bredband.com with ESMTP id <20061116223453.NQFF2545.mxfep03.bredband.com@ironport2.bredband.com>; Thu, 16 Nov 2006 23:34:53 +0100 Received: from c-58d8e055.107-1-64736c10.cust.bredbandsbolaget.se (HELO gatekeeper.pp.dyndns.biz) ([85.224.216.88]) by ironport2.bredband.com with ESMTP/TLS/AES256-SHA; 16 Nov 2006 23:34:53 +0100 Received: from phobos ([192.168.69.67]) by gatekeeper.pp.dyndns.biz (8.13.6/8.13.6) with ESMTP id kAGMYmUb012901; Thu, 16 Nov 2006 23:34:52 +0100 (CET) (envelope-from pp@pp.dyndns.biz) From: "Morgan" Sender: "pp" To: Date: Thu, 16 Nov 2006 23:34:47 +0100 Message-ID: <00f701c709cf$6c371d20$152ea8c0@phobos> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <455CB311.8040301@freebsd.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AccJsFUZ53nADhP1RDycyhIlM7RtTgAHKF0A Cc: freebsd-net@freebsd.org Subject: SV: Automatic TCP send socker buffer sizing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Nov 2006 22:35:02 -0000 > This is a patch adding automatic TCP send socket buffer > sizing. > The patch is available here: > > http://people.freebsd.org/~andre/tcp_auto_sndbuf-20061116.diff > > Any testers, especially with busy FTP servers, are very welcome. > Very nice indeed! I've actually been looking for something like this :-) I would very much like to try it out but I need to know if I can benefit from it with my setup. My network knowledge on this deep level is very limited so I need to ask a few questions that probably sounds stupid... but here we go: Would this patch only benefit traffic generated from or destined to the FreeBSD box itself or would it also benefit traffic generated behind it on a LAN if the FreeBSD box was configured as: a) a router with NAT b) a router without NAT c) a bridge only Add to this the extra complexity of pf with synproxy and modulate state. I simply don't know how (if at all) FreeBSD interacts with or manipulates packets going through it under any of these circumstances, so I have to ask to learn :-) The patch didn't apply cleanly to my 6.1-RELEASE. Since this patch was cross-posted to -current I guess it wasn't meant for me. Any chance you can provide a patch for 6.1-RELEASE? This is the output: # patch X-Original-To: freebsd-net@freebsd.org 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 0436416A594 for ; Thu, 16 Nov 2006 22:35:10 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id E7B3F43D80 for ; Thu, 16 Nov 2006 22:35:04 +0000 (GMT) (envelope-from freebsd-net@m.gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1Gkpp0-0007Zo-PW for freebsd-net@freebsd.org; Thu, 16 Nov 2006 23:35:02 +0100 Received: from mulderlab.f5.com ([205.229.151.151]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 16 Nov 2006 23:35:02 +0100 Received: from atkin901 by mulderlab.f5.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 16 Nov 2006 23:35:02 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Mark Atkinson Followup-To: gmane.os.freebsd.current Date: Thu, 16 Nov 2006 14:30:47 -0800 Lines: 38 Message-ID: References: <455CB311.8040301@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: mulderlab.f5.com User-Agent: KNode/0.10.4 Sender: news Cc: freebsd-current@freebsd.org Subject: Re: Automatic TCP send socker buffer sizing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Nov 2006 22:35:10 -0000 Andre Oppermann wrote: > This is a patch adding automatic TCP send socket buffer sizing. Normally > the socket buffers are static (either derived from global defaults or set > with setsockopt) and do not adapt to real network conditions. Two things > happen: a) your socket buffers are too small and you can't reach the full > potential of the network between both hosts; b) your socket buffers are > too big and you waste a lot of kernel memory for data just sitting around. > > With automatic TCP send socket buffers we can start with a small buffer > and quickly grow it in parallel with the TCP congestion window to match > real network conditions. > > FreeBSD has a default 32K send socket buffer. This supports a maximal > transfer rate of only slightly more than 2Mbit/s on a 100ms RTT trans- > continental link. Or at 200ms just above 1Mbit/s. With TCP send buffer > auto scaling and the default values below it supports 20Mbit/s at 100ms > and 10Mbit/s at 200ms. That's an improvement of factor 10, or 1000%. > > New sysctl's are: > > net.inet.tcp.sndbuf_auto=1 (enabled) > net.inet.tcp.sndbuf_inc=8192 (8K, step size) > net.inet.tcp.sndbuf_max=262144 (256K, growth limit) > > The patch is available here: > > http://people.freebsd.org/~andre/tcp_auto_sndbuf-20061116.diff > > Any testers, especially with busy FTP servers, are very welcome. The patch at this address seems incomplete and only contains changes to tcp_output.c. Notably missing is the SB_AUTOSIZE bitfield definition. -- Mark Atkinson atkin901@yahoo.com (!wired)?(coffee++):(wired); From owner-freebsd-net@FreeBSD.ORG Thu Nov 16 22:43:48 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 BD60F16A407 for ; Thu, 16 Nov 2006 22:43:48 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id D299143D53 for ; Thu, 16 Nov 2006 22:43:45 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 38251 invoked from network); 16 Nov 2006 22:35:59 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 16 Nov 2006 22:35:59 -0000 Message-ID: <455CE9A2.6030900@freebsd.org> Date: Thu, 16 Nov 2006 23:43:46 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Andre Oppermann References: <455CB311.8040301@freebsd.org> In-Reply-To: <455CB311.8040301@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: Automatic TCP send socker buffer sizing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Nov 2006 22:43:48 -0000 Andre Oppermann wrote: > This is a patch adding automatic TCP send socket buffer sizing. Normally > the socket buffers are static (either derived from global defaults or set > with setsockopt) and do not adapt to real network conditions. Two things > happen: a) your socket buffers are too small and you can't reach the full > potential of the network between both hosts; b) your socket buffers are > too big and you waste a lot of kernel memory for data just sitting around. > > With automatic TCP send socket buffers we can start with a small buffer > and quickly grow it in parallel with the TCP congestion window to match > real network conditions. > > FreeBSD has a default 32K send socket buffer. This supports a maximal > transfer rate of only slightly more than 2Mbit/s on a 100ms RTT trans- > continental link. Or at 200ms just above 1Mbit/s. With TCP send buffer > auto scaling and the default values below it supports 20Mbit/s at 100ms > and 10Mbit/s at 200ms. That's an improvement of factor 10, or 1000%. > > New sysctl's are: > > net.inet.tcp.sndbuf_auto=1 (enabled) > net.inet.tcp.sndbuf_inc=8192 (8K, step size) > net.inet.tcp.sndbuf_max=262144 (256K, growth limit) > > The patch is available here: > > http://people.freebsd.org/~andre/tcp_auto_sndbuf-20061116.diff The patch was missing the changes to tcp_usrreq.c and socketvar.h. I've replaced it with an updated one. Please fetch again. -- Andre From owner-freebsd-net@FreeBSD.ORG Thu Nov 16 22:49:04 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 149D916A415 for ; Thu, 16 Nov 2006 22:49:04 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C02B43D53 for ; Thu, 16 Nov 2006 22:49:02 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 38329 invoked from network); 16 Nov 2006 22:41:17 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 16 Nov 2006 22:41:17 -0000 Message-ID: <455CEAE0.1060603@freebsd.org> Date: Thu, 16 Nov 2006 23:49:04 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Morgan References: <00f701c709cf$6c371d20$152ea8c0@phobos> In-Reply-To: <00f701c709cf$6c371d20$152ea8c0@phobos> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: SV: Automatic TCP send socker buffer sizing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Nov 2006 22:49:04 -0000 Morgan wrote: >> This is a patch adding automatic TCP send socket buffer >> sizing. > > > >> The patch is available here: >> >> http://people.freebsd.org/~andre/tcp_auto_sndbuf-20061116.diff >> >> Any testers, especially with busy FTP servers, are very welcome. >> > > > Very nice indeed! I've actually been looking for something like this :-) I > would very much like to try it out but I need to know if I can benefit from > it with my setup. My network knowledge on this deep level is very limited so > I need to ask a few questions that probably sounds stupid... but here we go: > > Would this patch only benefit traffic generated from or destined to the > FreeBSD box itself or would it also benefit traffic generated behind it on a > LAN if the FreeBSD box was configured as: > > a) a router with NAT > > b) a router without NAT > > c) a bridge only > > Add to this the extra complexity of pf with synproxy and modulate state. I > simply don't know how (if at all) FreeBSD interacts with or manipulates > packets going through it under any of these circumstances, so I have to ask > to learn :-) It helps only if the FreeBSD box is the sender of data on a TCP connection. In all the cases you've listed there it doesn't (and can't) help. It would help though if you were running a full http proxy on it. > The patch didn't apply cleanly to my 6.1-RELEASE. Since this patch was > cross-posted to -current I guess it wasn't meant for me. Any chance you can > provide a patch for 6.1-RELEASE? This is the output: I'll do a backport to RELENG_6 tomorrow when I'm back in the office. > # patch Hmm... Looks like a unified diff to me... > The text leading up to this was: > -------------------------- > |Index: tcp_output.c > |=================================================================== > |RCS file: /home/ncvs/src/sys/netinet/tcp_output.c,v > |retrieving revision 1.121 > |diff -u -p -r1.121 tcp_output.c > |--- tcp_output.c 22 Oct 2006 11:52:16 -0000 1.121 > |+++ tcp_output.c 16 Nov 2006 18:35:43 -0000 > -------------------------- > File to patch: /usr/src/sys/netinet/tcp_output.c > Patching file /usr/src/sys/netinet/tcp_output.c using Plan A... > Hunk #1 succeeded at 49 (offset 1 line). > Hunk #2 failed at 105. > Hunk #3 failed at 395. > 2 out of 3 hunks failed--saving rejects to > /usr/src/sys/netinet/tcp_output.c.rej > Done > > > > Lastly, is it enough to rebuild only the kernel after applying this patch? Yes. > Once again, sorry for these stupid questions but this is the only way for me > to learn and I really would like to have this patch running on my system. No problem. Your effort is appreciated. -- Andre From owner-freebsd-net@FreeBSD.ORG Fri Nov 17 09:30:52 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 4BFEE16A47B for ; Fri, 17 Nov 2006 09:30:52 +0000 (UTC) (envelope-from wstud@wp.pl) Received: from mx1.wp.pl (mx1.wp.pl [212.77.101.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E37943D49 for ; Fri, 17 Nov 2006 09:30:51 +0000 (GMT) (envelope-from wstud@wp.pl) Received: (wp-smtpd smtp.wp.pl 15911 invoked from network); 17 Nov 2006 10:30:50 +0100 Received: from poczta-6.free.wp-sa.pl (HELO localhost) ([10.1.1.13]) (envelope-sender ) by smtp.wp.pl (WP-SMTPD) with SMTP for ; 17 Nov 2006 10:30:50 +0100 Date: Fri, 17 Nov 2006 10:30:49 +0100 From: "Robert M." To: freebsd-net@freebsd.org Message-ID: <455d8149b7306@wp.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 8bit Content-Disposition: inline X-Mailer: Interfejs WWW nowej poczty Wirtualnej Polski X-User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.7) Gecko/20060917 K-Meleon/1.02 Organization: Nowa Poczta Wirtualnej Polski S.A. http://www.wp.pl/ X-WP-IP: 193.24.221.171 X-WP-AV: skaner antywirusowy poczty Wirtualnej Polski S. A. X-WP-SPAM: NO AS1=NO AS2=NO(0.500026) AS3=NO AS4=NO AS5=NO Subject: ipsec-tools problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 17 Nov 2006 09:30:52 -0000 Hi, ipsec-tools-0.6.6 installed No matter what racoon.conf file I use I'm getting the following info when running racoon in foreground mode: 2006-11-17 10:26:28: DEBUG: caught rtm:2, need update interface address list 2006-11-17 10:26:28: DEBUG: msg 1 not interesting 2006-11-17 10:26:28: DEBUG: caught rtm:2, need update interface address list 2006-11-17 10:26:28: DEBUG: msg 1 not interesting 2006-11-17 10:26:28: DEBUG: caught rtm:2, need update interface address list 2006-11-17 10:26:29: DEBUG: msg 1 not interesting 2006-11-17 10:26:29: DEBUG: caught rtm:2, need update interface address list 2006-11-17 10:26:29: DEBUG: msg 1 not interesting 2006-11-17 10:26:29: DEBUG: caught rtm:2, need update interface address list Racoon does not work. xl0: flags=8843 mtu 1500 options=1 inet 61.110.11.250 netmask 0xfffffff8 broadcast 61.110.11.255 ether 00:04:75:c1:d7:76 media: Ethernet autoselect (10baseT/UTP) status: active Also, there are 3 interfaces with /24 local networks. Please help, Robert ---------------------------------------------------- Każda legenda ma swój początek - zobacz, jak James Bond stał się agentem 007! Film Casino Royale w kinach od 17 listopada. http://klik.wp.pl/?adr=http%3A%2F%2Fadv.reklama.wp.pl%2Fas%2Fblond.html&sid=932 From owner-freebsd-net@FreeBSD.ORG Fri Nov 17 09:48:43 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 4DD2F16A523 for ; Fri, 17 Nov 2006 09:48:43 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (reverse-25.fdn.fr [80.67.176.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id EF30843D4C for ; Fri, 17 Nov 2006 09:48:42 +0000 (GMT) (envelope-from vanhu@zeninc.net) Received: by smtp.zeninc.net (smtpd, from userid 1000) id 413DB3F17; Fri, 17 Nov 2006 10:48:41 +0100 (CET) Date: Fri, 17 Nov 2006 10:48:41 +0100 From: VANHULLEBUS Yvan To: freebsd-net@freebsd.org Message-ID: <20061117094840.GA21429@zen.inc> References: <455d8149b7306@wp.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <455d8149b7306@wp.pl> User-Agent: All mail clients suck. This one just sucks less. Subject: Re: ipsec-tools problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 17 Nov 2006 09:48:43 -0000 On Fri, Nov 17, 2006 at 10:30:49AM +0100, Robert M. wrote: > Hi, Hi. > ipsec-tools-0.6.6 installed Did you use port's default options, or did you change some of them ? > No matter what racoon.conf file I use I'm getting the following > info when running racoon in foreground mode: > > 2006-11-17 10:26:28: DEBUG: caught rtm:2, need update interface address list > 2006-11-17 10:26:28: DEBUG: msg 1 not interesting > 2006-11-17 10:26:28: DEBUG: caught rtm:2, need update interface address list > 2006-11-17 10:26:28: DEBUG: msg 1 not interesting > 2006-11-17 10:26:28: DEBUG: caught rtm:2, need update interface address list > 2006-11-17 10:26:29: DEBUG: msg 1 not interesting > 2006-11-17 10:26:29: DEBUG: caught rtm:2, need update interface address list > 2006-11-17 10:26:29: DEBUG: msg 1 not interesting > 2006-11-17 10:26:29: DEBUG: caught rtm:2, need update interface address list Such messages can happen, and it is normally not a problem. But they shouldn't happen so often ! > Racoon does not work. If your interfaces are always updated, it may cause some problems. But could you give us more details about the "does not work" ? Could we have your kernel version, one of the racoon.conf used, and some details about what is working and what doesn't work ? Yvan. -- NETASQ http://www.netasq.com From owner-freebsd-net@FreeBSD.ORG Fri Nov 17 10:24:11 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 43BDE16A403 for ; Fri, 17 Nov 2006 10:24:11 +0000 (UTC) (envelope-from greg@bestnet.kharkov.ua) Received: from relay.bestnet.ua (relay.bestnet.ua [193.124.57.92]) by mx1.FreeBSD.org (Postfix) with ESMTP id 94B6243D4C for ; Fri, 17 Nov 2006 10:24:10 +0000 (GMT) (envelope-from greg@bestnet.kharkov.ua) Received: from relay.bestnet.ua (db.bestnet.ua [127.0.0.1]) by relay.bestnet.ua (Postfix) with ESMTP id 73D73FB0039 for ; Fri, 17 Nov 2006 12:24:04 +0200 (EET) Received: from [80.92.224.11] (greg.bestnet.kharkov.ua [80.92.224.11]) by relay.bestnet.ua (Postfix) with ESMTP id 4F5C7FB0014 for ; Fri, 17 Nov 2006 12:24:04 +0200 (EET) Message-ID: <455D8DF2.2020105@bestnet.kharkov.ua> Date: Fri, 17 Nov 2006 12:24:50 +0200 From: Gregory Edigarov User-Agent: Thunderbird 1.5.0.7 (X11/20061114) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: How to test a firewall with NAT? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 17 Nov 2006 10:24:11 -0000 Hello Everybody, I am trying to move one of my servers/routers from linux/iptables to freebsd/pf, and need a methodology of testing the pf firewall ruleset before it will go in production. I cannot experiment on live network, because it's a busy server. I only have one other machine available. What can I do and what tool can you recommend? Thank you. -- With best regards, Gregory Edigarov From owner-freebsd-net@FreeBSD.ORG Fri Nov 17 10:34:48 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 60ED016A40F for ; Fri, 17 Nov 2006 10:34:48 +0000 (UTC) (envelope-from greg@bestnet.kharkov.ua) Received: from relay.bestnet.ua (relay.bestnet.ua [193.124.57.92]) by mx1.FreeBSD.org (Postfix) with ESMTP id DB51143D5D for ; Fri, 17 Nov 2006 10:34:47 +0000 (GMT) (envelope-from greg@bestnet.kharkov.ua) Received: from relay.bestnet.ua (db.bestnet.ua [127.0.0.1]) by relay.bestnet.ua (Postfix) with ESMTP id 73BA6FB003A for ; Fri, 17 Nov 2006 12:34:46 +0200 (EET) Received: from [80.92.224.11] (greg.bestnet.kharkov.ua [80.92.224.11]) by relay.bestnet.ua (Postfix) with ESMTP id 53362FB0014 for ; Fri, 17 Nov 2006 12:34:45 +0200 (EET) Message-ID: <455D9074.3090300@bestnet.kharkov.ua> Date: Fri, 17 Nov 2006 12:35:32 +0200 From: Gregory Edigarov User-Agent: Thunderbird 1.5.0.7 (X11/20061114) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: How to test a pf firewall with nat X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 17 Nov 2006 10:34:48 -0000 Hello Everybody, I am trying to move one of my servers/routers from linux/iptables to freebsd/pf, and need a methodology of testing the pf firewall ruleset before it will go in production. I cannot experiment on live network, because it's a busy server. I only have one other machine available. What can I do and what tool can you recommend? Thank you. -- With best regards, Gregory Edigarov From owner-freebsd-net@FreeBSD.ORG Fri Nov 17 13:09:12 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 6C3DE16A4A7 for ; Fri, 17 Nov 2006 13:09:12 +0000 (UTC) (envelope-from nick.george@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.173]) by mx1.FreeBSD.org (Postfix) with ESMTP id C4E5343D58 for ; Fri, 17 Nov 2006 13:09:08 +0000 (GMT) (envelope-from nick.george@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so622146uge for ; Fri, 17 Nov 2006 05:09:07 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=WTXKRKQvl6ijwdNsMa29GWQFpN3F6Bwjd0ytOvu6ULeiPJ9/2If8RrvUoc+mwAdpMpJyxUswHu/PbY1LwE9EoHaHOqJZFU6L0xTmtwZwvGdb9KSHRD9oBrkL5Tk3WOiezFQvt6ImyCbK+w9miETeoEi0/wHePQYeEK2ugx/wtNo= Received: by 10.78.58.11 with SMTP id g11mr1827469hua.1163768947294; Fri, 17 Nov 2006 05:09:07 -0800 (PST) Received: by 10.78.182.3 with HTTP; Fri, 17 Nov 2006 05:09:06 -0800 (PST) Message-ID: <862cde3b0611170509w6979dd00yeabbc0fce0b98353@mail.gmail.com> Date: Fri, 17 Nov 2006 14:09:06 +0100 From: "Nicholas George" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: FreeBSD 6.X if_bridge and IPFW fwd/divert support X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 17 Nov 2006 13:09:12 -0000 Greetings, Does anyone know if IPFW fwd and/or divert work with if_bridge under FreeBSD 6.x? Will Luigi's 4.X patches to enable fwd on bridges work under 6.X? even using if_bridge? Regards, Nick From owner-freebsd-net@FreeBSD.ORG Fri Nov 17 14:02:44 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 54C5016A412 for ; Fri, 17 Nov 2006 14:02:44 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1D7B443D5F for ; Fri, 17 Nov 2006 14:02:30 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 48802 invoked from network); 17 Nov 2006 13:54:36 -0000 Received: from dotat.atdotat.at (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 17 Nov 2006 13:54:36 -0000 Message-ID: <455DC0F4.1070309@freebsd.org> Date: Fri, 17 Nov 2006 15:02:28 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b) Gecko/20050217 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <455CB311.8040301@freebsd.org> In-Reply-To: <455CB311.8040301@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Automatic TCP send socker buffer sizing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 17 Nov 2006 14:02:44 -0000 Andre Oppermann wrote: > With automatic TCP send socket buffers we can start with a small buffer > and quickly grow it in parallel with the TCP congestion window to match > real network conditions. > > The patch is available here: > > http://people.freebsd.org/~andre/tcp_auto_sndbuf-20061116.diff > > Any testers, especially with busy FTP servers, are very welcome. A RELENG_6 version (for FreeBSD 6.x) of the patch is here: http://people.freebsd.org/~andre/tcp_auto_sndbuf-20061116-RELENG_6.diff Just apply this patch and recompile your kernel. It is activated by default. Be aware that all socket buffer sizing events get logged to syslog under LOG_DEBUG. This may affect overall system performance and you may want to disable logging to disk of this in syslogd.conf. -- Andre From owner-freebsd-net@FreeBSD.ORG Fri Nov 17 17:40:58 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 AD34716A415; Fri, 17 Nov 2006 17:40:58 +0000 (UTC) (envelope-from pp@pp.dyndns.biz) Received: from mxfep01.bredband.com (mxfep01.bredband.com [195.54.107.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C74F43D45; Fri, 17 Nov 2006 17:40:56 +0000 (GMT) (envelope-from pp@pp.dyndns.biz) Received: from ironport2.bredband.com ([195.54.107.84] [195.54.107.84]) by mxfep01.bredband.com with ESMTP id <20061117174056.KFC17968.mxfep01.bredband.com@ironport2.bredband.com>; Fri, 17 Nov 2006 18:40:56 +0100 Received: from c-58d8e055.107-1-64736c10.cust.bredbandsbolaget.se (HELO gatekeeper.pp.dyndns.biz) ([85.224.216.88]) by ironport2.bredband.com with ESMTP/TLS/AES256-SHA; 17 Nov 2006 18:40:55 +0100 Received: from phobos ([192.168.69.67]) by gatekeeper.pp.dyndns.biz (8.13.6/8.13.6) with ESMTP id kAHHkSKp001185; Fri, 17 Nov 2006 18:46:32 +0100 (CET) (envelope-from pp@pp.dyndns.biz) From: "Morgan" Sender: "pp" To: Date: Fri, 17 Nov 2006 18:40:48 +0100 Message-ID: <013901c70a6f$84d7eee0$152ea8c0@phobos> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <455DC0F4.1070309@freebsd.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AccKUb82ur/NrvZ0Ri67/tQE/3b1QwAHM5Zg Cc: freebsd-net@freebsd.org Subject: SV: Automatic TCP send socker buffer sizing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 17 Nov 2006 17:40:58 -0000 > A RELENG_6 version (for FreeBSD 6.x) of the patch is here: > > http://people.freebsd.org/~andre/tcp_auto_sndbuf-20061116-RELE > NG_6.diff > > Just apply this patch and recompile your kernel. It is > activated by default. Downloaded, applied, recompiled, installed and rebooted without any errors. I did however add the sysctl variables to my /etc/sysctl.conf just in case. > Be aware that all socket buffer sizing events get logged to > syslog under LOG_DEBUG. Does this mean they will automatically show up in /var/log/debug.log? > This may affect overall system > performance and you may want to disable logging to disk of > this in syslogd.conf. I could use some help with the syntax for this... :-) And a final question: Will this feature work regardless of what side initiates the TCP connection? Or will I have to instruct my ftp-users to use active mode only when they transfer files to/from my FreeBSD box? Regards Morgan From owner-freebsd-net@FreeBSD.ORG Fri Nov 17 17:59:30 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 F3B8916A47C for ; Fri, 17 Nov 2006 17:59:29 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5258843D77 for ; Fri, 17 Nov 2006 17:59:24 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 51730 invoked from network); 17 Nov 2006 17:51:29 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 17 Nov 2006 17:51:29 -0000 Message-ID: <455DF87D.8040604@freebsd.org> Date: Fri, 17 Nov 2006 18:59:25 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Morgan References: <013901c70a6f$84d7eee0$152ea8c0@phobos> In-Reply-To: <013901c70a6f$84d7eee0$152ea8c0@phobos> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: SV: Automatic TCP send socker buffer sizing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 17 Nov 2006 17:59:30 -0000 Morgan wrote: >> A RELENG_6 version (for FreeBSD 6.x) of the patch is here: >> >> http://people.freebsd.org/~andre/tcp_auto_sndbuf-20061116-RELE >> NG_6.diff >> >> Just apply this patch and recompile your kernel. It is >> activated by default. > > Downloaded, applied, recompiled, installed and rebooted without any errors. Good. > I did however add the sysctl variables to my /etc/sysctl.conf just in case. Unnecessary. ;-) >> Be aware that all socket buffer sizing events get logged to >> syslog under LOG_DEBUG. > > Does this mean they will automatically show up in /var/log/debug.log? Yes, or in /var/log/messages. >> This may affect overall system >> performance and you may want to disable logging to disk of >> this in syslogd.conf. > > I could use some help with the syntax for this... :-) I'd remove "kern.debug" from the /var/log/messages line and comment out the /var/log/debug.log line for the time being after you see a couple of lines with tcp_output: ... > And a final question: Will this feature work regardless of what side > initiates the TCP connection? Or will I have to instruct my ftp-users to use > active mode only when they transfer files to/from my FreeBSD box? It doesn't matter which side opens the connection. -- Andre From owner-freebsd-net@FreeBSD.ORG Fri Nov 17 18:41:12 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 B01E816A4A7; Fri, 17 Nov 2006 18:41:12 +0000 (UTC) (envelope-from pieter@thedarkside.nl) Received: from mail.thelostparadise.com (aberdeen.thelostparadise.com [193.202.115.174]) by mx1.FreeBSD.org (Postfix) with ESMTP id EFDA643D49; Fri, 17 Nov 2006 18:41:11 +0000 (GMT) (envelope-from pieter@thedarkside.nl) Received: from [192.168.1.11] (s55915f73.adsl.wanadoo.nl [85.145.95.115]) by mail.thelostparadise.com (Postfix) with ESMTP id 4D63B61C25; Fri, 17 Nov 2006 19:41:10 +0100 (CET) Message-ID: <455E0244.1070903@thedarkside.nl> Date: Fri, 17 Nov 2006 19:41:08 +0100 From: Pieter de Boer User-Agent: Thunderbird 1.5.0.7 (X11/20061018) MIME-Version: 1.0 To: Andre Oppermann References: <455CB311.8040301@freebsd.org> In-Reply-To: <455CB311.8040301@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: Automatic TCP send socker buffer sizing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 17 Nov 2006 18:41:12 -0000 Andre Oppermann wrote: > With automatic TCP send socket buffers we can start with a small buffer > and quickly grow it in parallel with the TCP congestion window to match > real network conditions. Are you planning to implement something similar for the receive path? -- Pieter From owner-freebsd-net@FreeBSD.ORG Fri Nov 17 18:59:27 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 EA48C16A40F for ; Fri, 17 Nov 2006 18:59:27 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1CCD343D49 for ; Fri, 17 Nov 2006 18:59:26 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 52696 invoked from network); 17 Nov 2006 18:51:31 -0000 Received: from dotat.atdotat.at (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 17 Nov 2006 18:51:31 -0000 Message-ID: <455E068D.1030000@freebsd.org> Date: Fri, 17 Nov 2006 19:59:25 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b) Gecko/20050217 MIME-Version: 1.0 To: Pieter de Boer References: <455CB311.8040301@freebsd.org> <455E0244.1070903@thedarkside.nl> In-Reply-To: <455E0244.1070903@thedarkside.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: Automatic TCP send socker buffer sizing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 17 Nov 2006 18:59:28 -0000 Pieter de Boer wrote: > Andre Oppermann wrote: > > >> With automatic TCP send socket buffers we can start with a small buffer >> and quickly grow it in parallel with the TCP congestion window to match >> real network conditions. > > Are you planning to implement something similar for the receive path? Yes, but it's a bit harder. -- Andre From owner-freebsd-net@FreeBSD.ORG Fri Nov 17 19:25:25 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 E895616A403 for ; Fri, 17 Nov 2006 19:25:25 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4CA0643D46 for ; Fri, 17 Nov 2006 19:25:25 +0000 (GMT) (envelope-from freebsd-net@m.gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1Gl9Kg-0002a9-QX for freebsd-net@freebsd.org; Fri, 17 Nov 2006 20:25:03 +0100 Received: from mulderlab.f5.com ([205.229.151.151]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 17 Nov 2006 20:25:02 +0100 Received: from atkin901 by mulderlab.f5.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 17 Nov 2006 20:25:02 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Mark Atkinson Followup-To: gmane.os.freebsd.current Date: Fri, 17 Nov 2006 11:22:09 -0800 Lines: 50 Message-ID: References: <455CB311.8040301@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: mulderlab.f5.com User-Agent: KNode/0.10.4 Sender: news Cc: freebsd-current@freebsd.org Subject: Re: Automatic TCP send socker buffer sizing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 17 Nov 2006 19:25:26 -0000 Andre Oppermann wrote: > This is a patch adding automatic TCP send socket buffer sizing. Normally > the socket buffers are static (either derived from global defaults or set > with setsockopt) and do not adapt to real network conditions. Two things > happen: a) your socket buffers are too small and you can't reach the full > potential of the network between both hosts; b) your socket buffers are > too big and you waste a lot of kernel memory for data just sitting around. > > With automatic TCP send socket buffers we can start with a small buffer > and quickly grow it in parallel with the TCP congestion window to match > real network conditions. > > FreeBSD has a default 32K send socket buffer. This supports a maximal > transfer rate of only slightly more than 2Mbit/s on a 100ms RTT trans- > continental link. Or at 200ms just above 1Mbit/s. With TCP send buffer > auto scaling and the default values below it supports 20Mbit/s at 100ms > and 10Mbit/s at 200ms. That's an improvement of factor 10, or 1000%. > > New sysctl's are: > > net.inet.tcp.sndbuf_auto=1 (enabled) > net.inet.tcp.sndbuf_inc=8192 (8K, step size) > net.inet.tcp.sndbuf_max=262144 (256K, growth limit) > > The patch is available here: > > http://people.freebsd.org/~andre/tcp_auto_sndbuf-20061116.diff > > Any testers, especially with busy FTP servers, are very welcome. Did some minimal testing and it appears to apply cleanly and log: ov 17 11:15:27 ftp kernel: tcp_output: inc sockbuf, old 33304, new 41496, sb_cc 31776, snd_wnd 40544, sendwnd 20272 Nov 17 11:15:27 ftp kernel: tcp_output: inc sockbuf, old 41496, new 49688, sb_cc 38232, snd_wnd 46336, sendwnd 27512 Nov 17 11:15:27 ftp kernel: tcp_output: inc sockbuf, old 49688, new 57880, sb_cc 46960, snd_wnd 63712, sendwnd 40544 Nov 17 11:15:27 ftp kernel: tcp_output: inc sockbuf, old 57880, new 66072, sb_cc 55568, snd_wnd 63712, sendwnd 60816 Nov 17 11:15:27 ftp kernel: tcp_output: inc sockbuf, old 66072, new 74264, sb_cc 65168, snd_wnd 63712, sendwnd 63712 Nov 17 11:15:27 ftp kernel: tcp_output: inc sockbuf, old 74264, new 82456, sb_cc 65168, snd_wnd 63712, sendwnd 63712 -- Mark Atkinson atkin901@yahoo.com (!wired)?(coffee++):(wired); From owner-freebsd-net@FreeBSD.ORG Fri Nov 17 20:41:59 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 BFFAD16A40F for ; Fri, 17 Nov 2006 20:41:59 +0000 (UTC) (envelope-from jdp@polstra.com) Received: from blake.polstra.com (blake.polstra.com [64.81.189.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3308943D49 for ; Fri, 17 Nov 2006 20:41:58 +0000 (GMT) (envelope-from jdp@polstra.com) Received: from strings.polstra.com (strings.polstra.com [64.81.189.67]) by blake.polstra.com (8.13.6/8.13.6) with ESMTP id kAHKfw2w085643; Fri, 17 Nov 2006 12:41:58 -0800 (PST) (envelope-from jdp@polstra.com) Message-ID: X-Mailer: XFMail 1.5.5 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Fri, 17 Nov 2006 12:41:58 -0800 (PST) From: John Polstra To: freebsd-net@freebsd.org Cc: Jack Vogel Subject: Serious em problems under -current on two different platforms X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 17 Nov 2006 20:41:59 -0000 Folks, I'm using -current from 2006-11-16 05:00 UTC and find that my em interfaces are unusable on two quite different platforms. I've tried a lot of things to make sure it's not a local fubar here, including doing a "make release" using a virgin source tree and installing fresh from the resulting CD (with GENERIC kernel). I also have a netbootable CD image that is part of the project I'm working on, and it admittedly has some minor mods to the kernel. I booted that exact same image on two different platforms with em devices in them, and got the same results as when I used the virgin FreeBSD CD. I don't think this is caused by the recent MSI support. I get the same results when I disable it by adding "hw.pci.enable_msi=0" and "hw.pci.enable_msix=0" to my /boot/loader.conf file. (And I confirmed that MSI wasn't being used when I did that.) The symptoms are complicated, so let's focus on one of the machines. It's a Dell 1950 with two dual-core 3.0 GHz Xeons in it. The em devices look like this (it's a dual-port card PCI-Express card): em0@pci11:0:0: class=0x020000 card=0x125e8086 chip=0x105e8086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = 'PRO/1000 PT' class = network subclass = ethernet em1@pci11:0:1: class=0x020000 card=0x125e8086 chip=0x105e8086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = 'PRO/1000 PT' class = network subclass = ethernet Starting with a freshly-booted system, we see this ifconfig output, as expected: em0: flags=8802 mtu 1500 options=18b ether 00:0e:0c:6f:0e:18 media: Ethernet autoselect (1000baseTX ) status: active em1: flags=8802 mtu 1500 options=18b ether 00:0e:0c:6f:0e:19 media: Ethernet autoselect (1000baseTX ) status: active Now I do "ifconfig em0 10.5.1.1/24" and then ping that address from another machine on the LAN: thin# ping 10.5.1.1 PING 10.5.1.1 (10.5.1.1): 56 data bytes 64 bytes from 10.5.1.1: icmp_seq=0 ttl=64 time=0.524 ms Then nothing after the first reply. Leaving the ping running on the other machine, I configure the address a 2nd time on the Dell with "ifconfig em0 10.5.1.1/24". Still no response. Next, ifconfig em0 down and then up again. After a few seconds, the ping responses start coming in and continue to work. Try a flood ping from the other machine: it works fine. I kill the flood ping and go have lunch for a half-hour, then start up a normal 1-per-second ping from the other machine: thin# ping 10.5.1.1 PING 10.5.1.1 (10.5.1.1): 56 data bytes 64 bytes from 10.5.1.1: icmp_seq=0 ttl=64 time=0.612 ms [then nothing] This time, I check the vmstat -i output a few times, and see that em0 isn't generating any interrupts. I ifconfig em0 down and then up, and the pings start working again. Now, leaving that 1-per-second ping running, I start messing with em1. I do "ifconfig em1 10.6.1.1/24", and within a few seconds, the pings on em0 stop responding. Again em0 isn't generating interrupts. Pings to em1 aren't working, either. I ifconfig em1 down and then up. The pings still aren't working. I set em1's address again with "ifconfig em1 10.6.1.1/24", and the pings start working. Now I ping em0 from the other machine and find that it works, too. Hallelujah! Now both interfaces are working at the same time. But what's the key to getting to this point? I let the pings run for awhile. Pretty soon, both of them stop working again. The other machine is a Tyan 2721 with dual Xeons in it. Its dual-port NIC is on the motherboard, and it looks like this: em0@pci7:1:0: class=0x020000 card=0x10118086 chip=0x10108086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82546EB Dual Port Gigabit Ethernet Controller (Copper)' class = network subclass = ethernet em1@pci7:1:1: class=0x020000 card=0x10118086 chip=0x10108086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82546EB Dual Port Gigabit Ethernet Controller (Copper)' class = network subclass = ethernet I can't get either port to send any packets at all. When I try, the driver reports transmit watchdog timeouts. Is this stuff working for anybody at all? John From owner-freebsd-net@FreeBSD.ORG Sat Nov 18 07:52:41 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9527116B35C for ; Sat, 18 Nov 2006 07:52:41 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 79ED145425 for ; Sat, 18 Nov 2006 04:51:27 +0000 (GMT) (envelope-from jfvogel@gmail.com) Received: by wx-out-0506.google.com with SMTP id s18so1042787wxc for ; Fri, 17 Nov 2006 20:51:27 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=PhckOxnG1XsYiKnIo7/SJZDGdq54fOuhYhSfDP1c52bo+2UQDG5RmCO9GbdV4Z8n4Otf2f+OFbkhdOq1rI82CrSzaX4uvdvhDsUVBGW5SvO0NH9RBB9un5bIF+n7fWZSt7A5tD9F+rNp/0joab5DRfIjpG0SFEV7q86XNjUE3gs= Received: by 10.90.115.9 with SMTP id n9mr2135843agc.1163797993352; Fri, 17 Nov 2006 13:13:13 -0800 (PST) Received: by 10.35.118.6 with HTTP; Fri, 17 Nov 2006 13:13:13 -0800 (PST) Message-ID: <2a41acea0611171313k56d19031kca505b8b2117a7e3@mail.gmail.com> Date: Fri, 17 Nov 2006 13:13:13 -0800 From: "Jack Vogel" To: "John Polstra" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Cc: freebsd-net@freebsd.org Subject: Re: Serious em problems under -current on two different platforms X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 18 Nov 2006 07:52:41 -0000 On 11/17/06, John Polstra wrote: > Folks, I'm using -current from 2006-11-16 05:00 UTC and find that my > em interfaces are unusable on two quite different platforms. I've > tried a lot of things to make sure it's not a local fubar here, > including doing a "make release" using a virgin source tree and > installing fresh from the resulting CD (with GENERIC kernel). I also > have a netbootable CD image that is part of the project I'm working > on, and it admittedly has some minor mods to the kernel. I booted > that exact same image on two different platforms with em devices in > them, and got the same results as when I used the virgin FreeBSD CD. > > I don't think this is caused by the recent MSI support. I get the > same results when I disable it by adding "hw.pci.enable_msi=0" and > "hw.pci.enable_msix=0" to my /boot/loader.conf file. (And I confirmed > that MSI wasn't being used when I did that.) > > The symptoms are complicated, so let's focus on one of the machines. > It's a Dell 1950 with two dual-core 3.0 GHz Xeons in it. The em > devices look like this (it's a dual-port card PCI-Express card): > > em0@pci11:0:0: class=0x020000 card=0x125e8086 chip=0x105e8086 rev=0x04 hdr=0x00 > vendor = 'Intel Corporation' > device = 'PRO/1000 PT' > class = network > subclass = ethernet > em1@pci11:0:1: class=0x020000 card=0x125e8086 chip=0x105e8086 rev=0x04 hdr=0x00 > vendor = 'Intel Corporation' > device = 'PRO/1000 PT' > class = network > subclass = ethernet > > Starting with a freshly-booted system, we see this ifconfig output, > as expected: > > em0: flags=8802 mtu 1500 > options=18b > ether 00:0e:0c:6f:0e:18 > media: Ethernet autoselect (1000baseTX ) > status: active > em1: flags=8802 mtu 1500 > options=18b > ether 00:0e:0c:6f:0e:19 > media: Ethernet autoselect (1000baseTX ) > status: active > > Now I do "ifconfig em0 10.5.1.1/24" and then ping that address from > another machine on the LAN: > > thin# ping 10.5.1.1 > PING 10.5.1.1 (10.5.1.1): 56 data bytes > 64 bytes from 10.5.1.1: icmp_seq=0 ttl=64 time=0.524 ms > > Then nothing after the first reply. Leaving the ping running on the > other machine, I configure the address a 2nd time on the Dell with > "ifconfig em0 10.5.1.1/24". Still no response. Next, ifconfig em0 > down and then up again. After a few seconds, the ping responses > start coming in and continue to work. Try a flood ping from the > other machine: it works fine. > > I kill the flood ping and go have lunch for a half-hour, then start > up a normal 1-per-second ping from the other machine: > > thin# ping 10.5.1.1 > PING 10.5.1.1 (10.5.1.1): 56 data bytes > 64 bytes from 10.5.1.1: icmp_seq=0 ttl=64 time=0.612 ms > [then nothing] > > This time, I check the vmstat -i output a few times, and see that > em0 isn't generating any interrupts. I ifconfig em0 down and then > up, and the pings start working again. > > Now, leaving that 1-per-second ping running, I start messing with > em1. I do "ifconfig em1 10.6.1.1/24", and within a few seconds, the > pings on em0 stop responding. Again em0 isn't generating > interrupts. Pings to em1 aren't working, either. I ifconfig em1 > down and then up. The pings still aren't working. I set em1's > address again with "ifconfig em1 10.6.1.1/24", and the pings start > working. Now I ping em0 from the other machine and find that it > works, too. Hallelujah! Now both interfaces are working at the > same time. But what's the key to getting to this point? > > I let the pings run for awhile. Pretty soon, both of them stop > working again. > > The other machine is a Tyan 2721 with dual Xeons in it. Its > dual-port NIC is on the motherboard, and it looks like this: > > em0@pci7:1:0: class=0x020000 card=0x10118086 chip=0x10108086 rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > device = '82546EB Dual Port Gigabit Ethernet Controller (Copper)' > class = network > subclass = ethernet > em1@pci7:1:1: class=0x020000 card=0x10118086 chip=0x10108086 rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > device = '82546EB Dual Port Gigabit Ethernet Controller (Copper)' > class = network > subclass = ethernet > > I can't get either port to send any packets at all. When I try, the > driver reports transmit watchdog timeouts. > > Is this stuff working for anybody at all? This sounds bizarrely broken, can you try and back off the deltas of if_em.[ch] and find a point where it works? I have not been making the changes into CURRENT, and I am busy with some important Intel tasks that I must get done, so it would help knowing when it broke. Thanks, Jack From owner-freebsd-net@FreeBSD.ORG Sat Nov 18 07:58:33 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9C57C16A8DB for ; Sat, 18 Nov 2006 07:58:33 +0000 (UTC) (envelope-from julian@elischer.org) Received: from customer-domains.icp-qv1-irony7.iinet.net.au (customer-domains.icp-qv1-irony7.iinet.net.au [203.59.1.128]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3182D43D53 for ; Sat, 18 Nov 2006 07:58:30 +0000 (GMT) (envelope-from julian@elischer.org) Received: from 203-166-240-248.dyn.iinet.net.au (HELO [192.168.3.2]) ([203.166.240.248]) by customer-domains.icp-qv1-irony7.iinet.net.au with ESMTP; 18 Nov 2006 15:58:26 +0800 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAOhKXkXLpvD4dGdsb2JhbAANjDkB X-IronPort-AV: i="4.09,436,1157299200"; d="scan'208"; a="430367588:sNHT59482076" Message-ID: <455EBD23.6030102@elischer.org> Date: Sat, 18 Nov 2006 15:58:27 +0800 From: Julian Elischer User-Agent: Thunderbird 1.5.0.5 (X11/20060804) MIME-Version: 1.0 To: Nicholas George References: <862cde3b0611170509w6979dd00yeabbc0fce0b98353@mail.gmail.com> In-Reply-To: <862cde3b0611170509w6979dd00yeabbc0fce0b98353@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD 6.X if_bridge and IPFW fwd/divert support X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 18 Nov 2006 07:58:33 -0000 Nicholas George wrote: > Greetings, > > Does anyone know if IPFW fwd and/or divert work with if_bridge under > FreeBSD 6.x? I have patches to do this I have permission from my emplyer to commit them but there are other things that need to be done first. > > Will Luigi's 4.X patches to enable fwd on bridges work under 6.X? even > using if_bridge? > > Regards, > Nick > _______________________________________________ > 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 Nov 18 10:23:03 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4EFC416A403 for ; Sat, 18 Nov 2006 10:23:03 +0000 (UTC) (envelope-from hell@aldiablo.net) Received: from ms01.schabkar.com (dns1.schabkar.com [81.223.20.147]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2176943D46 for ; Sat, 18 Nov 2006 10:22:59 +0000 (GMT) (envelope-from hell@aldiablo.net) Received: from localhost (localhost [127.0.0.1]) by ms01.schabkar.com (Postfix on Fedora) with ESMTP id 0BD6973C005 for ; Sat, 18 Nov 2006 11:23:01 +0100 (CET) Received: from ms01.schabkar.com ([127.0.0.1]) by localhost (ms01.schabkar.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04701-04 for ; Sat, 18 Nov 2006 11:22:53 +0100 (CET) Received: from OLDBOY (85-124-200-39.dynamic.xdsl-line.inode.at [85.124.200.39]) by ms01.schabkar.com (Postfix on Fedora) with ESMTP id 312A873C002 for ; Sat, 18 Nov 2006 11:22:53 +0100 (CET) Date: Sat, 18 Nov 2006 11:22:22 +0100 From: Stefan X-Mailer: The Bat! (v1.62r) X-Priority: 3 (Normal) Message-ID: <1763166525.20061118112222@aldiablo.net> To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at schabkar.com Subject: ping round trip times freebsd - windows X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Stefan List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Nov 2006 10:23:03 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Greetings, First I would like to say hello to everyone and want to admit, that I'm not that expert in freebsd ;-). I've took an interest in freebsd at v5.0 and have been playing around since that (technical curiosity). Due to my job I only work with Windows-machines/servers. Until now I was happy not to be confronted with major problems in freebsd and it worked very well so far (for my personal needs) - but I just recognized something strange... I have an test-machine at work (w2003 server) and freebsd running in an vmware (via dhcp). I tried simple round trip time measurements via ping-command but got different results. I'm pretty sure, that this might only be a config or commandline issue, but I didn't find anything useful so far. (man ping included). Ping shows (in my knowledge) the complete round trip time a packet needs for echo_request and echo_reply. In case of the freebsd ouput it seems to me, that it is only one-way. Please find the results for the two different commands below - maybe someone has an hint for me. freebsd: PING xxx.xxx.xxx.xxx (xxx.xxx.xxx.xxx): 56 data bytes 64 bytes from xxx.xxx.xxx.xxx: icmp_seq=0 ttl=128 time=151.541 ms 64 bytes from xxx.xxx.xxx.xxx: icmp_seq=1 ttl=128 time=146.279 ms 64 bytes from xxx.xxx.xxx.xxx: icmp_seq=2 ttl=128 time=169.988 ms 64 bytes from xxx.xxx.xxx.xxx: icmp_seq=3 ttl=128 time=151.510 ms 64 bytes from xxx.xxx.xxx.xxx: icmp_seq=4 ttl=128 time=141.120 ms 64 bytes from xxx.xxx.xxx.xxx: icmp_seq=5 ttl=128 time=153.513 ms 64 bytes from xxx.xxx.xxx.xxx: icmp_seq=6 ttl=128 time=168.278 ms 64 bytes from xxx.xxx.xxx.xxx: icmp_seq=7 ttl=128 time=148.961 ms 64 bytes from xxx.xxx.xxx.xxx: icmp_seq=8 ttl=128 time=159.754 ms 64 bytes from xxx.xxx.xxx.xxx: icmp_seq=9 ttl=128 time=199.485 ms - --- xxx.xxx.xxx.xxx ping statistics --- 10 packets transmitted, 10 packets received, 0% packet loss round-trip min/avg/max/stddev = 141.120/159.043/199.485/16.033 ms windows 2003 server (vmware-host): Pinging xxx.xxx.xxx.xxx with 32 bytes of data: Reply from xxx.xxx.xxx.xxx: bytes=32 time=289ms TTL=125 Reply from xxx.xxx.xxx.xxx: bytes=32 time=290ms TTL=125 Reply from xxx.xxx.xxx.xxx: bytes=32 time=387ms TTL=125 Reply from xxx.xxx.xxx.xxx: bytes=32 time=352ms TTL=125 Reply from xxx.xxx.xxx.xxx: bytes=32 time=372ms TTL=125 Reply from xxx.xxx.xxx.xxx: bytes=32 time=311ms TTL=125 Reply from xxx.xxx.xxx.xxx: bytes=32 time=289ms TTL=125 Ping statistics for xxx.xxx.xxx.xxx: Packets: Sent = 7, Received = 7, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 289ms, Maximum = 387ms, Average = 327ms The connection is approx. around half the world The rtt is definitely between 300-600ms. Current networking setup looks like the following: test-machine---[LAN]---[Firewall]----Internet----[Firewall]---[LAN]---target-server Current pc setup: source: Windows 2003 standard edition vmware 5.5 freebsd 6.1 release (generic kernel install; no further configuration changes) destination: windows 2003 server As soon as the ping pass the firewall and will be routed (either vpn or mpls) it seems that the rtt is only the half-way time. best regards Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (MingW32) iQEVAwUBRV7e5asBSJW3BUHpAQP5ugf8CCUDbtRoGBrsh1ujAheeLzCYa2X1bCu7 PD9PMvs2alQTgn7C4OD8ihpUJ2HdJodWxVfJefe6T60rPV2PuQu+qNsPy69Rt6JW IhIDtbvOaagpF/PmjMT7yZ+1TstAK3QUX4SEWQYRyRogg2tGYYWv8hfQl14VEbGU QpGuAZqXe3Qw056J2cweTzE5x9xX3lnihGxGq1brlPI4EPpT2LtfUy2GVFShrDeZ IGYO4HAebQD8TPf1iPdBPlpuQXbvVos5he/SPKbFTx1NYpJ46vWVrfgc7VQdffWD DCAtfIV+BzI9aiCrPtw3++XCp2rdyzKA8puYoK6IPimlALsiroMJUA== =cSOY -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Sat Nov 18 16:21:39 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 73ECE16A40F for ; Sat, 18 Nov 2006 16:21:39 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id D62E843D46 for ; Sat, 18 Nov 2006 16:21:34 +0000 (GMT) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id kAIGLbV3060229; Sat, 18 Nov 2006 11:21:37 -0500 (EST) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.6/8.13.3) with ESMTP id kAIGLblS075218 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 18 Nov 2006 11:21:37 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <200611181621.kAIGLblS075218@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 18 Nov 2006 11:21:44 -0500 To: John Polstra From: Mike Tancsa In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner2 X-Virus-Status: Clean Cc: freebsd-net@freebsd.org Subject: Re: Serious em problems under -current on two different platforms X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 18 Nov 2006 16:21:39 -0000 At 08:24 PM 11/17/2006, John Polstra wrote: >Thanks for the reply, Mike. I think the PCI-Express risers in this >box are 8X. That's what the Dell spec sheet says, anyway. Havent had too much experience with PCIe riser cards yet, but have had some experience with bad PCI-X risers. Any way to test to see if its a bad riser card? The behaviour almost looks to be a hardware issue ? >Are you using both ports of the NIC? With an older driver, em0 >worked fine but em1 did not. Yes, actually I am testing the forwarding ability of the box. So far with FreeBSD, I found that the 2 kernel options below #options ADAPTIVE_GIANT # Giant mutex is adaptive. options NO_ADAPTIVE_MUTEXES and turning on fast_forwarding increases performance and responsiveness of the box. Straight Routing test One Stream (http://www.tancsa.com/blast.jpg) OS pps Linux 581,309.81 FreeBSD HEAD 441,559.50 RELENG6 i386 407,403.00 RELENG6 i386 FastFWD 557,589.25 FreeBSD HEAD w Patch 422,294.13 FreeBSD HEAD w Patch FastFWD 567,290.00 AMD64 RELENG6 w FastFWD 574,591.88 The patch has some changes glebius@freebsd.org asked me to test. > > Do you have them on xover cables or a switch ? > >They are connected to a Dell gigabit switch which I haven't ever had >any problems with. any errors at the time on the switch port when things lock up ? ---Mike >John From owner-freebsd-net@FreeBSD.ORG Sat Nov 18 17:31:31 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B755E16A415 for ; Sat, 18 Nov 2006 17:31:31 +0000 (UTC) (envelope-from South@pamoconnell.com) Received: from [195.210.225.166] (BSN-210-225-166.dial-up.dsl.siol.net [195.210.225.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id B901643E2A for ; Sat, 18 Nov 2006 17:30:10 +0000 (GMT) (envelope-from South@pamoconnell.com) Message-ID: <000a01c70b37$29d6d380$a6e1d2c3@xy40b87df0ffca> From: "Brazilian" To: freebsd-net@freebsd.org Date: Sat, 18 Nov 2006 18:29:55 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0006_01C70B3F.8B98F190" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Mail X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 18 Nov 2006 17:31:32 -0000 ------=_NextPart_000_0006_01C70B3F.8B98F190 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Stocks Quotes in attachement Sa series Acid test Indiakrish Africans in. Said Loading Indous in Senate finally passed Anant back Dravid. Smith spots chink am armoury of should am. In pics Nepalese. Chinas state integral part am Coverage! Searchin a Indiatimes Search Print Adsall. ------=_NextPart_000_0006_01C70B3F.8B98F190--