From owner-freebsd-net@FreeBSD.ORG Sun Aug 31 15:03:27 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB4961065685 for ; Sun, 31 Aug 2008 15:03:27 +0000 (UTC) (envelope-from marin.bek@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.183]) by mx1.freebsd.org (Postfix) with ESMTP id 770B58FC1B for ; Sun, 31 Aug 2008 15:03:27 +0000 (UTC) (envelope-from marin.bek@gmail.com) Received: by py-out-1112.google.com with SMTP id p76so889966pyb.10 for ; Sun, 31 Aug 2008 08:03:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type; bh=BNKEaZY66yfvNdZEQ2KNRsuubtrZV+m9SQWwFMiuQnQ=; b=uADCO1mfmwKadgcz2f2zPv/XGuzgtF6Od0l0+vpnh510yyQe0xfJa5bHhAmhgJlDCg ah2DJrmdikKCx7QmyrbyzLhc/BdQLCwcXXQ5cLmgq6aE1C79hJuTXqL/3+OzxA9rUFzI Ha+zkgQTURaX6azyE2Wvxdgbt8aP53EgUl7d8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=hiaaTJgG3cni/cQi8C0BU2AKL09NSpDIWCnJRZk9foDfSn+OwrMYVomQU63yvgV7Fv uquMT1dDc+R8HXDjkfVd2cNY+goIuX3XzIlNRziju0MmHW7pszbelPVbELJgyKc7eP6G fzVpzkSzX+0KuiLg6X7FXMSE9dgo5IIdhi5Nw= Received: by 10.65.241.20 with SMTP id t20mr10433843qbr.62.1220193079782; Sun, 31 Aug 2008 07:31:19 -0700 (PDT) Received: by 10.65.123.19 with HTTP; Sun, 31 Aug 2008 07:31:19 -0700 (PDT) Message-ID: Date: Sun, 31 Aug 2008 16:31:19 +0200 From: "Marin Bek" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: 7.0 ipfw nat confusion 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, 31 Aug 2008 15:03:27 -0000 Hello, I've been using ipfw + natd successfully before, but now have problems using the implemented nat functionality, though I find it a great improvement. Simply NAT-in internal network to external is working flawlessly by just: ipfw nat 1 config if $extern ipfw add 100 nat 1 log ip from any to any But when I add some redirect_port to configuration, it doesn't work. External->internal translation failes (tcpdump unreachable...). Command is accepted, general NAT works fine, but ports are not forwarded. So, I did the following: ipfw nat 1 config if $internal redirect_port tcp 192.168.5.2:5000 5000 redirect_port udp 192.168.5.2:5000 5000 where 192.168.5.X is the internal network, and $internal the NIC connected to this interface. Starting a simple tcp/udp application on one of the internal clients (5.2) on port 5000, and testing it on that computer is successful. But when I attempt to connect to the service via 5.1 (the router internal IP) - no luck. tcpdump-ing gives "192.168.5.1 > 192.168.5.2: ICMP 192.168.5.1 udp port 5000 unreachable" Am I missing something? Should I add some extra rules to the ipfw (it is set to allow_all)? Similar setup worked fine with natd+ipfw. Thanks... From owner-freebsd-net@FreeBSD.ORG Sun Aug 31 15:07:53 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7CF11065677 for ; Sun, 31 Aug 2008 15:07:53 +0000 (UTC) (envelope-from robert@blacquiere.nl) Received: from mail.blacquiere.nl (static.196.62.47.78.clients.your-server.de [78.47.62.196]) by mx1.freebsd.org (Postfix) with ESMTP id 677398FC13 for ; Sun, 31 Aug 2008 15:07:53 +0000 (UTC) (envelope-from robert@blacquiere.nl) Received: from [192.168.201.5] (helo=shell.blacquiere.nl) by mail.blacquiere.nl with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZoK4-000IzP-2E; Sun, 31 Aug 2008 16:54:36 +0200 Date: Sun, 31 Aug 2008 16:54:27 +0200 From: Robert Blacquiere To: freebsd-net@freebsd.org Message-ID: <20080831145427.GG4324@shellvm.blacquiere.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i X-Disclaimer: running FreeBSD X-SA-Exim-Connect-IP: 192.168.201.5 X-SA-Exim-Mail-From: robert@blacquiere.nl X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on mail.blacquiere.nl X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.2.4 X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail.blacquiere.nl) Subject: Weird tunneling issue 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, 31 Aug 2008 15:07:53 -0000 Hi, I'me having some strange issues with openvpn when a gre tunnel is active. When reverting to gif tunneling the problem does not occur. What happens. I setup a openvpn tunnel to a acces server with a gre tunnel active. Setup of the openvpn tunnel succeeds ant have connection. After a view seconds, between 10 and 60, the openvpn session gets a SIGUSR1 on the client site. Over the gre tunnel is a link to a radius server for authentication of the openvpn clients. When i use a gif tunnel between the server and the radius server, this does not happen. To make it more strange if i have a gre tunnel to some other host active and have the gif tunnel between the access and radius server, the connection (openvpn) is rock stable. gre1: flags=9051 metric 0 mtu 1476 tunnel inet $ip_accessserver --> $ip_radiusserver inet 10.A.A.240 --> 10.A.A.241 netmask 0xffffffff gif1: flags=8051 metric 0 mtu 1280 tunnel inet $ip_accessserver --> $ip_radiusserver inet 10.A.A.102 --> 10.A.A.101 netmask 0xffffffff tap0: flags=8843 metric 0 mtu 1500 ether 00:bd:fa:5f:c6:00 inet 172.16.0.1 netmask 0xffffff00 broadcast 172.16.0.255 Opened by PID 28781 I'me running FreeBSD 7.0-Stable of end jul. on a amd64. Any clues how i could attack this problem or find a solution? Regards Robert -- Microsoft: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming or what? OpenBSD: Hey guys you left some holes out there! From owner-freebsd-net@FreeBSD.ORG Mon Sep 1 04:12:15 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A516A106567F for ; Mon, 1 Sep 2008 04:12:15 +0000 (UTC) (envelope-from ganbold@micom.mng.net) Received: from publicd.ub.mng.net (publicd.ub.mng.net [202.179.0.88]) by mx1.freebsd.org (Postfix) with ESMTP id 615B88FC15 for ; Mon, 1 Sep 2008 04:12:15 +0000 (UTC) (envelope-from ganbold@micom.mng.net) Received: from [202.179.0.164] (helo=daemon.micom.mng.net) by publicd.ub.mng.net with esmtpa (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ka0ll-000Jyf-3r; Mon, 01 Sep 2008 12:12:01 +0800 Message-ID: <48BB6B95.4010103@micom.mng.net> Date: Mon, 01 Sep 2008 12:12:05 +0800 From: Ganbold User-Agent: Thunderbird 2.0.0.12 (X11/20080415) MIME-Version: 1.0 To: "freebsd-net@freebsd.org" X-Enigmail-Version: 0.95.6 OpenPGP: id=78F6425E Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Gleb Smirnoff , rizzo@iet.unipi.it, Julian Elischer Subject: IPFW_TABLES_MAX in src/sbin/ipfw/ipfw2.c 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, 01 Sep 2008 04:12:15 -0000 Hi, Sorry for sending this third time (2 to freebsd-ipfw, 1 to freebsd-net). I'm trying to make small changes in ipfw2.c code (RELENG_7), but make fails with following error: v02# make cc -O2 -fno-strict-aliasing -pipe -Wno-pointer-sign -c /usr/src/sbin/ipfw/ipfw2.c /usr/src/sbin/ipfw/ipfw2.c: In function 'table_handler': /usr/src/sbin/ipfw/ipfw2.c:5941: error: 'IPFW_TABLES_MAX' undeclared (first use in this function) /usr/src/sbin/ipfw/ipfw2.c:5941: error: (Each undeclared identifier is reported only once /usr/src/sbin/ipfw/ipfw2.c:5941: error: for each function it appears in.) *** Error code 1 IPFW_TABLES_MAX seems like defined in netinet/ip_fw.h, which is included in ipfw2.c: #define IPFW_INTERNAL /* Access to protected structures in ip_fw.h. */ ... #include ... I'm trying to read IPFW_TABLES_MAX and print all tables IP in loop. Any idea how to solve this problem? Basically I'm trying to add small feature (list IPs of all tables) to /sbin/ipfw something like: ipfw table all list I know it is possible to write small shell script to display all the tables and IPs in it. However I thought it might be useful to have such small feature in /sbin/ipfw. Correct me if I'm wrong here. thanks, Ganbold -- Understanding is always the understanding of a smaller problem in relation to a bigger problem. -- P. D. Ouspensky From owner-freebsd-net@FreeBSD.ORG Mon Sep 1 05:20:28 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 973101067A21 for ; Mon, 1 Sep 2008 05:20:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 882EE8FC1D for ; Mon, 1 Sep 2008 05:20:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m815K4km009467 for ; Mon, 1 Sep 2008 05:20:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m815K4sd009466; Mon, 1 Sep 2008 05:20:04 GMT (envelope-from gnats) Date: Mon, 1 Sep 2008 05:20:04 GMT Message-Id: <200809010520.m815K4sd009466@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Pekka Savola Cc: Subject: kern/121298: [panic] Fatal trap 12: page fault while in kernel mode (em0 taskq) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Pekka Savola List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2008 05:20:28 -0000 The following reply was made to PR kern/121298; it has been noted by GNATS. From: Pekka Savola To: bug-followup@freebsd.org Cc: Subject: kern/121298: [panic] Fatal trap 12: page fault while in kernel mode (em0 taskq) Date: Mon, 1 Sep 2008 08:14:42 +0300 (EEST) FYI, I got hit by this (at least it seems identical) as well pretty soon after I enabled SMP on this box. With UP kernel, I have not seen such core dumps. This is 7.1-PRERELEASE (Cvsup of RELENG_7 as of Aug 31 2008). Polling is not compiled in the kernel. The device has: options=9b It's either of these (actually I'm not sure which one. probably the former): 02:0c.1 Ethernet controller: Intel Corporation 82546EB Gigabit Ethernet Controller (Copper) (rev 01) Subsystem: Intel Corporation PRO/1000 MT Dual Port Server Adapter Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 28 Memory at dfdc0000 (64-bit, non-prefetchable) I/O ports at ec80 Capabilities: [dc] Power Management version 2 Capabilities: [e4] PCI-X non-bridge device Capabilities: [f0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- 06:07.0 Ethernet controller: Intel Corporation 82541GI Gigabit Ethernet Controller (rev 05) Subsystem: Dell Unknown device 016d Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 48 Memory at dfae0000 (32-bit, non-prefetchable) I/O ports at dcc0 Capabilities: [dc] Power Management version 2 Capabilities: [e4] PCI-X non-bridge device ============== Unread portion of the kernel message buffer: <110>ipfw: 20 Deny TCP [2001:0:d5c7:a2ca:2cfe:116b:2b6a:554d]:55056 [2001:0:4137:9e50:2894:3b42:b7b4:d119]:44889 in via stf0 TPTE at 0xbfca027c IS ZERO @ VA 2809f000 pakernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x14 fault code = supervisor read, page not present instruction pointer = 0x20:0xc05c17de stack pointer = 0x28:0xe53cea08 frame pointer = 0x28:0xe53cea28 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = resume, IOPL = 0 current process = 21 (em2 taskq) trap number = 12 panic: page fault cpuid = 0 Uptime: 3h59m45s Physical memory: 2039 MB Dumping 174 MB: 159 143 127 111 95 79 63 47 31 15 #0 doadump () at pcpu.h:196 196 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) bt #0 doadump () at pcpu.h:196 #1 0xc058cc57 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc058cf19 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:572 #3 0xc073b9bc in trap_fatal (frame=0xe53ce9c8, eva=20) at /usr/src/sys/i386/i386/trap.c:939 #4 0xc073c30f in trap (frame=0xe53ce9c8) at /usr/src/sys/i386/i386/trap.c:320 #5 0xc072204b in calltrap () at /usr/src/sys/i386/i386/exception.s:159 #6 0xc05c17de in propagate_priority (td=0xc555fd20) at /usr/src/sys/kern/subr_turnstile.c:272 #7 0xc05c2618 in turnstile_wait (ts=0xc4d0e5a0, owner=0xc555fd20, queue=Variable "queue" is not available. ) at /usr/src/sys/kern/subr_turnstile.c:739 #8 0xc057fe1e in _mtx_lock_sleep (m=0xc080c7bc, tid=3302831200, opts=0, file=0x0, line=0) at /usr/src/sys/kern/kern_mutex.c:420 #9 0xc0738002 in pmap_enter (pmap=0xc081ade0, va=3369541632, m=0xc1a11728, prot=7 '\a', wired=1) at /usr/src/sys/i386/i386/pmap.c:2345 #10 0xc06db888 in kmem_malloc (map=0xc107108c, size=4096, flags=257) at /usr/src/sys/vm/vm_kern.c:416 #11 0xc06d1ba7 in page_alloc (zone=0xc10601e0, bytes=4096, pflag=0xe53ceb5f "\002", wait=257) at /usr/src/sys/vm/uma_core.c:959 #12 0xc06d0e5c in slab_zalloc (zone=0xc10601e0, wait=257) at /usr/src/sys/vm/uma_core.c:822 #13 0xc06d1344 in uma_zone_slab (zone=0xc10601e0, flags=1) at /usr/src/sys/vm/uma_core.c:2014 #14 0xc06d440a in uma_zalloc_arg (zone=0xc10601e0, udata=0xe53cec04, flags=1) at /usr/src/sys/vm/uma_core.c:2115 #15 0xc049781c in em_get_buf (adapter=0xc4dac000, i=122) at mbuf.h:469 #16 0xc049abf9 in em_rxeof (adapter=0xc4dac000, count=99) at /usr/src/sys/dev/e1000/if_em.c:4420 #17 0xc049b717 in em_handle_rxtx (context=0xc4dac000, pending=1) at /usr/src/sys/dev/e1000/if_em.c:1676 #18 0xc05c0185 in taskqueue_run (queue=0xc4dc2a80) at /usr/src/sys/kern/subr_taskqueue.c:282 #19 0xc05c038b in taskqueue_thread_loop (arg=0xc4dac370) at /usr/src/sys/kern/subr_taskqueue.c:401 #20 0xc0569ab9 in fork_exit (callout=0xc05c02d0 , arg=0xc4dac370, frame=0xe53ced38) at /usr/src/sys/kern/kern_fork.c:804 #21 0xc07220c0 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:264 (kgdb) up 17 #17 0xc049b717 in em_handle_rxtx (context=0xc4dac000, pending=1) at /usr/src/sys/dev/e1000/if_em.c:1676 1676 if (em_rxeof(adapter, adapter->rx_process_limit) != 0) (kgdb) up 16 #16 0xc049abf9 in em_rxeof (adapter=0xc4dac000, count=99) at /usr/src/sys/dev/e1000/if_em.c:4420 4420 if (em_get_buf(adapter, i) != 0) { From owner-freebsd-net@FreeBSD.ORG Mon Sep 1 08:30:09 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18BC7106569F for ; Mon, 1 Sep 2008 08:30:09 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 029648FC08 for ; Mon, 1 Sep 2008 08:30:09 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m818U8mG052001 for ; Mon, 1 Sep 2008 08:30:08 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m818U8K2051996; Mon, 1 Sep 2008 08:30:08 GMT (envelope-from gnats) Date: Mon, 1 Sep 2008 08:30:08 GMT Message-Id: <200809010830.m818U8K2051996@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: "Paul B. Mahol" Cc: Subject: Re: kern/125181: [ndis] [patch] with wep enters kdb.enter.unknown, panics X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Paul B. Mahol" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2008 08:30:09 -0000 The following reply was made to PR kern/125181; it has been noted by GNATS. From: "Paul B. Mahol" To: "Andrew Thompson" Cc: "Coleman Kane" , bug-followup@freebsd.org Subject: Re: kern/125181: [ndis] [patch] with wep enters kdb.enter.unknown, panics Date: Mon, 1 Sep 2008 09:57:42 +0200 On 7/17/08, Andrew Thompson wrote: > On Thu, Jul 17, 2008 at 12:09:52PM -0400, Coleman Kane wrote: >> Andrew, >> >> I got directed to this PR by onemda@gmail.com (Paul D. Mahol), who's >> been helping me track down some edge cases in the if_ndis locking >> rewrite. I am not 100% familiar with the locking semantics in play here >> (IEEE80211 and VAPs), so I wanted to run it by you before I determine >> that it seems to be working well for me. > > I dont think ndis should be reaching into the net80211 lock. Now that > ndis uses a regular mutex its a good chance to add mtx_asserts in the > right places and get the locking up to speed. I will try to post a patch > soon unless someone beats be to it. > > Andrew > I got hit by this bug again, my only option is to switch to UP kernel until patch for this bug is finally committed. Subject of bug report is no more relevant, becuase this bug has nothing directly related with WEP. From owner-freebsd-net@FreeBSD.ORG Mon Sep 1 09:29:41 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B05D8106567C; Mon, 1 Sep 2008 09:29:41 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forwards4.yandex.ru (forwards4.yandex.ru [77.88.32.20]) by mx1.freebsd.org (Postfix) with ESMTP id 620468FC1A; Mon, 1 Sep 2008 09:29:41 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from smtp14.yandex.ru (smtp14.yandex.ru [77.88.32.84]) by forwards4.yandex.ru (Postfix) with ESMTP id 0E06D4C58A3; Mon, 1 Sep 2008 13:12:29 +0400 (MSD) Received: from ns.kirov.so-cdu.ru ([77.72.136.145]:13550 "EHLO [127.0.0.1]" smtp-auth: "bu7cher" TLS-CIPHER: "DHE-RSA-AES256-SHA keybits 256/256 version TLSv1/SSLv3" TLS-PEER-CN1: ) by mail.yandex.ru with ESMTP id S5177506AbYIAJMU (ORCPT + 4 others); Mon, 1 Sep 2008 13:12:20 +0400 X-Yandex-Spam: 1 X-Yandex-Front: smtp14 X-Yandex-TimeMark: 1220260340 X-MsgDayCount: 5 X-Comment: RFC 2476 MSA function at smtp14.yandex.ru logged sender identity as: bu7cher Message-ID: <48BBB1F1.2090302@yandex.ru> Date: Mon, 01 Sep 2008 13:12:17 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Ganbold References: <48BB6B95.4010103@micom.mng.net> In-Reply-To: <48BB6B95.4010103@micom.mng.net> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" , Gleb Smirnoff , rizzo@iet.unipi.it, Julian Elischer Subject: Re: IPFW_TABLES_MAX in src/sbin/ipfw/ipfw2.c 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, 01 Sep 2008 09:29:41 -0000 Ganbold wrote: > Hi, > > Sorry for sending this third time (2 to freebsd-ipfw, 1 to freebsd-net). > > I'm trying to make small changes in ipfw2.c code (RELENG_7), but make > fails with following error: > > v02# make > cc -O2 -fno-strict-aliasing -pipe -Wno-pointer-sign -c > /usr/src/sbin/ipfw/ipfw2.c > /usr/src/sbin/ipfw/ipfw2.c: In function 'table_handler': > /usr/src/sbin/ipfw/ipfw2.c:5941: error: 'IPFW_TABLES_MAX' undeclared > (first use in this function) > /usr/src/sbin/ipfw/ipfw2.c:5941: error: (Each undeclared identifier is > reported only once > /usr/src/sbin/ipfw/ipfw2.c:5941: error: for each function it appears in.) > *** Error code 1 > > IPFW_TABLES_MAX seems like defined in netinet/ip_fw.h, which is included > in ipfw2.c: > IPFW_TABLES_MAX protected by _KERNEL macro. This is why you get an error. -- WBR, Andrey V. Elsukov From owner-freebsd-net@FreeBSD.ORG Mon Sep 1 09:38:57 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB8AC106564A; Mon, 1 Sep 2008 09:38:57 +0000 (UTC) (envelope-from ganbold@micom.mng.net) Received: from publicd.ub.mng.net (publicd.ub.mng.net [202.179.0.88]) by mx1.freebsd.org (Postfix) with ESMTP id 839208FC1F; Mon, 1 Sep 2008 09:38:57 +0000 (UTC) (envelope-from ganbold@micom.mng.net) Received: from [202.179.0.164] (helo=daemon.micom.mng.net) by publicd.ub.mng.net with esmtpa (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ka5s0-000MNq-4E; Mon, 01 Sep 2008 17:38:48 +0800 Message-ID: <48BBB82C.3050008@micom.mng.net> Date: Mon, 01 Sep 2008 17:38:52 +0800 From: Ganbold User-Agent: Thunderbird 2.0.0.12 (X11/20080415) MIME-Version: 1.0 To: "Andrey V. Elsukov" References: <48BB6B95.4010103@micom.mng.net> <48BBB1F1.2090302@yandex.ru> In-Reply-To: <48BBB1F1.2090302@yandex.ru> X-Enigmail-Version: 0.95.6 OpenPGP: id=78F6425E Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" , Gleb Smirnoff , rizzo@iet.unipi.it, Julian Elischer Subject: Re: IPFW_TABLES_MAX in src/sbin/ipfw/ipfw2.c 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, 01 Sep 2008 09:38:58 -0000 Andrey V. Elsukov wrote: > Ganbold wrote: >> Hi, >> >> Sorry for sending this third time (2 to freebsd-ipfw, 1 to freebsd-net). >> >> I'm trying to make small changes in ipfw2.c code (RELENG_7), but make >> fails with following error: >> >> v02# make >> cc -O2 -fno-strict-aliasing -pipe -Wno-pointer-sign -c >> /usr/src/sbin/ipfw/ipfw2.c >> /usr/src/sbin/ipfw/ipfw2.c: In function 'table_handler': >> /usr/src/sbin/ipfw/ipfw2.c:5941: error: 'IPFW_TABLES_MAX' undeclared >> (first use in this function) >> /usr/src/sbin/ipfw/ipfw2.c:5941: error: (Each undeclared identifier is >> reported only once >> /usr/src/sbin/ipfw/ipfw2.c:5941: error: for each function it appears >> in.) >> *** Error code 1 >> >> IPFW_TABLES_MAX seems like defined in netinet/ip_fw.h, which is included >> in ipfw2.c: >> > > IPFW_TABLES_MAX protected by _KERNEL macro. This is why you get > an error. Yeah, my fault, I was looking around IPFW_INTERNAL and missed _KERNEL macro. I defined new sysctl variable in netinet/ip_fw2.c and now I'm able to get IPFW_TABLES_MAX via sysctl from /sbin/ipfw. Is it the way I should get constant protected by _KERNEL? Also should I PR my patch? Anyway here is the diff against RELENG_7. Please let me know if I'm doing something wrong here. ------------------------------------------------------------------- --- ip_fw2.c.orig 2008-09-01 17:31:57.000000000 +0800 +++ ip_fw2.c 2008-09-01 16:54:30.000000000 +0800 @@ -255,6 +255,8 @@ static u_int32_t dyn_count; /* # of dynamic rules */ static u_int32_t dyn_max = 4096; /* max # of dynamic rules */ +static u_int32_t tables_count = IPFW_TABLES_MAX; /* # of tables */ + SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, dyn_buckets, CTLFLAG_RW, &dyn_buckets, 0, "Number of dyn. buckets"); SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, curr_dyn_buckets, CTLFLAG_RD, @@ -265,6 +267,8 @@ &dyn_max, 0, "Max number of dyn. rules"); SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, static_count, CTLFLAG_RD, &static_count, 0, "Number of static rules"); +SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, tables_count, CTLFLAG_RD, + &tables_count, 0, "Number of tables"); SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, dyn_ack_lifetime, CTLFLAG_RW, &dyn_ack_lifetime, 0, "Lifetime of dyn. rules for acks"); SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, dyn_syn_lifetime, CTLFLAG_RW, ------------------------------------------------------------------- --- /usr/src/sbin/ipfw/ipfw2.c 2008-07-31 09:39:59.000000000 +0800 +++ ipfw2.c 2008-09-01 16:46:08.000000000 +0800 @@ -5860,24 +5860,30 @@ * ipfw table N add addr[/masklen] [value] * ipfw table N delete addr[/masklen] * ipfw table N flush - * ipfw table N list + * ipfw table N|all list */ static void table_handler(int ac, char *av[]) { ipfw_table_entry ent; ipfw_table *tbl; - int do_add; + int do_add, is_all = 0; char *p; socklen_t l; - uint32_t a; + uint32_t a, b, c; + size_t len; ac--; av++; if (ac && isdigit(**av)) { ent.tbl = atoi(*av); ac--; av++; + } else if (_substrcmp(*av, "all") == 0) { + ent.tbl = 0; + is_all = 1; + ac--; av++; } else errx(EX_USAGE, "table number required"); + NEED1("table needs command"); if (_substrcmp(*av, "add") == 0 || _substrcmp(*av, "delete") == 0) { @@ -5931,33 +5937,55 @@ if (do_cmd(IP_FW_TABLE_FLUSH, &ent.tbl, sizeof(ent.tbl)) < 0) err(EX_OSERR, "setsockopt(IP_FW_TABLE_FLUSH)"); } else if (_substrcmp(*av, "list") == 0) { - a = ent.tbl; - l = sizeof(a); - if (do_cmd(IP_FW_TABLE_GETSIZE, &a, (uintptr_t)&l) < 0) - err(EX_OSERR, "getsockopt(IP_FW_TABLE_GETSIZE)"); - l = sizeof(*tbl) + a * sizeof(ipfw_table_entry); - tbl = malloc(l); - if (tbl == NULL) - err(EX_OSERR, "malloc"); - tbl->tbl = ent.tbl; - if (do_cmd(IP_FW_TABLE_LIST, tbl, (uintptr_t)&l) < 0) - err(EX_OSERR, "getsockopt(IP_FW_TABLE_LIST)"); - for (a = 0; a < tbl->cnt; a++) { - unsigned int tval; - tval = tbl->ent[a].value; - if (do_value_as_ip) { - char tbuf[128]; - strncpy(tbuf, inet_ntoa(*(struct in_addr *) - &tbl->ent[a].addr), 127); - /* inet_ntoa expects network order */ - tval = htonl(tval); - printf("%s/%u %s\n", tbuf, tbl->ent[a].masklen, - inet_ntoa(*(struct in_addr *)&tval)); - } else { - printf("%s/%u %u\n", - inet_ntoa(*(struct in_addr *)&tbl->ent[a].addr), - tbl->ent[a].masklen, tval); + c = ent.tbl; + + if (is_all) { + len = sizeof(uint32_t); + + /* get IPFW_TABLES_MAX */ + if (sysctlbyname("net.inet.ip.fw.tables_count", + &c, &len, NULL, 0) == -1) + errx(1, "sysctlbyname(\"%s\")", + "net.inet.ip.fw.tables_count"); + + c -= 1; + } + + for (b = ent.tbl; b <= c; b++) { + a = b; + l = sizeof(b); + + if (do_cmd(IP_FW_TABLE_GETSIZE, &a, (uintptr_t)&l) < 0) + err(EX_OSERR, "getsockopt(IP_FW_TABLE_GETSIZE)"); + l = sizeof(*tbl) + a * sizeof(ipfw_table_entry); + tbl = malloc(l); + if (tbl == NULL) + err(EX_OSERR, "malloc"); + tbl->tbl = b; + if (do_cmd(IP_FW_TABLE_LIST, tbl, (uintptr_t)&l) < 0) + err(EX_OSERR, "getsockopt(IP_FW_TABLE_LIST)"); + + if (tbl->cnt && is_all) + printf("---table(%d)---\n", b); + + for (a = 0; a < tbl->cnt; a++) { + unsigned int tval; + tval = tbl->ent[a].value; + if (do_value_as_ip) { + char tbuf[128]; + strncpy(tbuf, inet_ntoa(*(struct in_addr *) + &tbl->ent[a].addr), 127); + /* inet_ntoa expects network order */ + tval = htonl(tval); + printf("%s/%u %s\n", tbuf, tbl->ent[a].masklen, + inet_ntoa(*(struct in_addr *)&tval)); + } else { + printf("%s/%u %u\n", + inet_ntoa(*(struct in_addr *)&tbl->ent[a].addr), + tbl->ent[a].masklen, tval); + } } + free(tbl); } } else errx(EX_USAGE, "invalid table command %s", *av); thanks, Ganbold -- Life is a grand adventure -- or it is nothing. -- Helen Keller From owner-freebsd-net@FreeBSD.ORG Mon Sep 1 11:06:59 2008 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9CC02106568A for ; Mon, 1 Sep 2008 11:06:59 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8C8668FC08 for ; Mon, 1 Sep 2008 11:06:59 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m81B6xHc068509 for ; Mon, 1 Sep 2008 11:06:59 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m81B6wpt068504 for freebsd-net@FreeBSD.org; Mon, 1 Sep 2008 11:06:58 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 1 Sep 2008 11:06:58 GMT Message-Id: <200809011106.m81B6wpt068504@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-net@FreeBSD.org 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, 01 Sep 2008 11:06:59 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri a kern/38554 net [patch] changing interface ipaddress doesn't seem to w s kern/39937 net ipstealth issue s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/92090 net [bge] bge0: watchdog timeout -- resetting f kern/92552 net A serious bug in most network drivers from 5.X to 6.X o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] s kern/105943 net Network stack may modify read-only mbuf chain copies o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/108542 net [bce]: Huge network latencies with 6.2-RELEASE / STABL o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o kern/109733 net [bge] bge link state issues [regression] o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112722 net [udp] IP v4 udp fragmented packet reject o kern/113842 net [ip6] PF_INET6 proto domain state can't be cleared wit o kern/114714 net [gre][patch] gre(4) is not MPSAFE and does not support o kern/114839 net [fxp] fxp looses ability to speak with traffic o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/116077 net [ip] [patch] 6.2-STABLE panic during use of multi-cast o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/116328 net [bge]: Solid hang with bge interface o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117423 net [vlan] Duplicate IP on different interfaces o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/118880 net [ip6] IP_RECVDSTADDR & IP_SENDSRCADDR not implemented o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/119345 net [ath] Unsuported Atheros 5424/2424 and CPU speedstep n o kern/119361 net [bge] bge(4) transmit performance problem o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o kern/120266 net [panic] gnugk causes kernel panic when closing UDP soc o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120966 net [rum] kernel panic with if_rum and WPA encryption o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 o kern/121983 net [fxp] fxp0 MBUF and PAE o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup [reg o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122082 net [in_pcb] NULL pointer dereference in in_pcbdrop o kern/122195 net [ed] Alignment problems in if_ed f kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122427 net [apm] [panic] apm and mDNSResponder cause panic during o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122685 net It is not visible passing packets in tcpdump o kern/122743 net [panic] vm_page_unwire: invalid wire count: 0 o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix f kern/122794 net [lagg] Kernel panic after brings lagg(8) up if NICs ar o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/123066 net [ipsec] [panic] kernel trap with ipsec o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 f kern/123172 net [bce] Watchdog timeout problems with if_bce f kern/123200 net [netgraph] Server failure due to netgraph mpd and dhcp o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123617 net [tcp] breaking connection when client downloading file o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o kern/123881 net [tcp] Turning on TCP blackholing causes slow localhost o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/124127 net [msk] watchdog timeout (missed Tx interrupts) -- recov o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124904 net [fxp] EEPROM corruption with Compaq NC3163 NIC o kern/125079 net [ppp] host routes added by ppp with gateway flag (regr f kern/125195 net [fxp] fxp(4) driver failed to initialize device Intel o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o bin/125922 net [patch] Deadlock in arp(8) o kern/126075 net [in] Network: internet control accesses beyond end of o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126469 net [fxp] [panic] fxp(4) related kernel panic o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126561 net [nlm] [patch] NLM (rpclockd) RPC UNLOCK failure (stall f kern/126564 net [ath] doesn't work with my PCI-E X1 wireless network a o kern/126688 net [ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126742 net [panic] kernel panic when sending file via ng_ubt(4) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o kern/126945 net [carp] CARP interface destruction with ifconfig destro 105 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o conf/23063 net [PATCH] for static ARP tables in rc.network o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". 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/64556 net [sis] if_sis short cable fix problems with NetGear FA3 o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 p kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/95267 net packet drops periodically appear o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/100519 net [netisr] suggestion to fix suboptimal network polling 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 o conf/107035 net [patch] bridge interface given in rc.conf not taking a o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o bin/117339 net [patch] route(8): loading routing management commands o kern/118727 net [netgraph] [patch] [request] add new ng_pf module a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o kern/119432 net [arp] route add -host -iface causes arp e f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121443 net [gif] LOR icmp6_input/nd6_lookup o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122068 net [ppp] ppp can not set the correct interface with pptpd o kern/122295 net [bge] bge Ierr rate increase (since 6.0R) [regression] o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122697 net [ath] Atheros card is not well supported o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge f kern/122839 net [multicast] FreeBSD 7 multicast routing problem o kern/122928 net [em] interface watchdog timeouts and stops receiving p o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) o kern/123892 net [tap] [patch] No buffer space available p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o bin/124004 net ifconfig(8): Cannot assign both an IP and a MAC addres o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124609 net [ipsec] [panic] ipsec 'remainder too big' panic with p o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/125181 net [ndis] [patch] with wep enters kdb.enter.unknown, pani o kern/125239 net [gre] kernel crash when using gre o kern/125258 net [socket] socket's SO_REUSEADDR option does not work f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125816 net [carp] [bridge] carp stuck in init when using bridge i o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/126339 net [ipw] ipw driver drops the connection o kern/126695 net rtfree messages and network disruption upon use of if_ o bin/126822 net wpa_supplicant(8): WPA PSK does not work in adhoc mode o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) 63 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Sep 1 11:42:42 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 26EFA1065679; Mon, 1 Sep 2008 11:42:42 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id F3EB48FC1A; Mon, 1 Sep 2008 11:42:41 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (remko@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m81BgfBh076231; Mon, 1 Sep 2008 11:42:41 GMT (envelope-from remko@freefall.freebsd.org) Received: (from remko@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m81BgfGa076227; Mon, 1 Sep 2008 11:42:41 GMT (envelope-from remko) Date: Mon, 1 Sep 2008 11:42:41 GMT Message-Id: <200809011142.m81BgfGa076227@freefall.freebsd.org> To: remko@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: remko@FreeBSD.org Cc: Subject: Re: kern/126984: [carp][patch] add carp userland notifications via devctl(4) 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, 01 Sep 2008 11:42:42 -0000 Synopsis: [carp][patch] add carp userland notifications via devctl(4) Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Mon Sep 1 11:42:22 UTC 2008 Responsible-Changed-Why: Carp is something networking related, bring it over. http://www.freebsd.org/cgi/query-pr.cgi?pr=126984 From owner-freebsd-net@FreeBSD.ORG Mon Sep 1 12:04:54 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DAB0510656D9 for ; Mon, 1 Sep 2008 12:04:54 +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 B42D18FC17 for ; Mon, 1 Sep 2008 12:04:54 +0000 (UTC) (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 3C2EC46C4E; Mon, 1 Sep 2008 08:04:54 -0400 (EDT) Date: Mon, 1 Sep 2008 13:04:54 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Anton Yuzhaninov In-Reply-To: <48AEDC40.6030901@citrin.ru> Message-ID: References: <48AEDC40.6030901@citrin.ru> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: bug in unix sockets garbage collector 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, 01 Sep 2008 12:04:54 -0000 On Fri, 22 Aug 2008, Anton Yuzhaninov wrote: > On servers where used unix sockets, sometimes thread taskq start to eat 100% > CPU: http://docs.FreeBSD.org/cgi/mid.cgi?474EFC5C.9060508 > > Addition info about this problem - when this occurs > > sysctl net.local.inflight show negative number. > > % sysctl net.local.inflight net.local.inflight: -3 > > And this condition become always true: > > if (local_unp_rights) > taskqueue_enqueue(taskqueue_thread, &unp_gc_task); > > It seems, that unp_rights decremented more often than incremented, or some > race exist. Hi Anton: On reviewing this code, I've identified at least one race condition that could lead to the behavior that you've spotted. It will probably take me a couple of days to produce a patch for you to try. However, could I ask you to file a PR for this problem, with the above and any related diagnostics, and when you receive the e-mail PR receipt, could you forward it to me so that I can take ownership of it? Thanks, Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-net@FreeBSD.ORG Mon Sep 1 12:39:11 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC1FF1065670 for ; Mon, 1 Sep 2008 12:39:11 +0000 (UTC) (envelope-from debarshi.ray@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by mx1.freebsd.org (Postfix) with ESMTP id 4E5708FC23 for ; Mon, 1 Sep 2008 12:39:11 +0000 (UTC) (envelope-from debarshi.ray@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so1228391fgb.35 for ; Mon, 01 Sep 2008 05:39:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to :to:subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=CbAv1W02Ht0eI1Rr+AicUCQoXW6xyCg0Mn0RMRu3Ah0=; b=eOkcthOoMTD87gw8zrvx1Kqz8gtmHPEuiKheSzwTThQw4Hnj3blYULTDFCRdBMNpiw +p+cUxerwguyWiSJWvPiz06lVIc5NipTEKT1edg8Vo4e2ejNGLJ6eb2aj2q3yzIkIOUx hJd4rD7JXikrLNRgWT6Tuq5Gjt3nffsatCPgw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=eLLW5/qcQMvVuSHtj79dB4NDQ1NUoiab6FoyqEbuevHRLruyAyWBl0tnwlLGrw7x1G Gt7ZOUNR9Ia6NH1uWZ9RQyGxnxtPW368jh2uW5w1qNIsKahSF5nUGx20LVV0OGFiV8x3 XQQ4WeQdVIlGSK2EfzVSmxO4D4PB68zwII8Zc= Received: by 10.187.191.19 with SMTP id t19mr1926928fap.87.1220270827913; Mon, 01 Sep 2008 05:07:07 -0700 (PDT) Received: by 10.187.245.8 with HTTP; Mon, 1 Sep 2008 05:07:07 -0700 (PDT) Message-ID: <3170f42f0809010507q6c37a9d5q19649bc261d7656d@mail.gmail.com> Date: Mon, 1 Sep 2008 17:37:07 +0530 From: "Debarshi Ray" To: "FreeBSD networking and TCP/IP list" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: reading routing table X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: debarshi.ray@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2008 12:39:11 -0000 I am implementing a library/utility which basically encompasses the features of the traditional route utilities and those of newer tools (like ip from iproute2), which are mostly specific to a particular kernel. The overpowering objective is to make the library/utility work uniformly across all different kernels, so that programs like NetworkManager have a portable library/utility to use instead of the Linux-kernel specific ip which is now being used. I was going through the FreeBSD and NetBSD documentation and the FreeBSD sources of netstat and route. I was suprised to see that while NetBSD's route implementation has a 'show' command, FreeBSD does not offer any such thing. Moreover it seems that one can not read the entire routing table using the PF_ROUTE sockets and RTM_GET returns information pertaining to only one destination. This suprised me because one can do such a thing with the Linux kernel's RTNETLINK. Is there a reason why this is so? Or is reading from /dev/kmem the only way to get a dump of the routing tables? Thanks, Debarshi From owner-freebsd-net@FreeBSD.ORG Mon Sep 1 12:54:12 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EBEAE106566C for ; Mon, 1 Sep 2008 12:54:12 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id C5A118FC14 for ; Mon, 1 Sep 2008 12:54:12 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 5509F15C486; Mon, 1 Sep 2008 08:54:12 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Mon, 01 Sep 2008 08:54:12 -0400 X-Sasl-enc: aJxzizDrqj/LC6o58QDXCIJeWI7PUHRpUVeszTGOIicH 1220273651 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 9A0A66BE9; Mon, 1 Sep 2008 08:54:11 -0400 (EDT) Message-ID: <48BBE5F2.4000108@FreeBSD.org> Date: Mon, 01 Sep 2008 13:54:10 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.14 (X11/20080514) MIME-Version: 1.0 To: debarshi.ray@gmail.com References: <3170f42f0809010507q6c37a9d5q19649bc261d7656d@mail.gmail.com> In-Reply-To: <3170f42f0809010507q6c37a9d5q19649bc261d7656d@mail.gmail.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD networking and TCP/IP list Subject: Re: reading routing table 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, 01 Sep 2008 12:54:13 -0000 Debarshi Ray wrote: > I am implementing a library/utility which basically encompasses the > features of the traditional route utilities and those of newer tools > (like ip from iproute2), which are mostly specific to a particular > kernel. The overpowering objective is to make the library/utility work > uniformly across all different kernels, so that programs like > NetworkManager have a portable library/utility to use instead of the > Linux-kernel specific ip which is now being used. > Why don't you just use XORP's FEA code? It already does all this under a BSD-type license. cheers BMS From owner-freebsd-net@FreeBSD.ORG Mon Sep 1 13:01:40 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DAA4A1065677 for ; Mon, 1 Sep 2008 13:01:40 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id B48148FC1F for ; Mon, 1 Sep 2008 13:01:40 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 3F20615BA71; Mon, 1 Sep 2008 09:01:40 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Mon, 01 Sep 2008 09:01:40 -0400 X-Sasl-enc: fAlZZrmhh0opQmQKeOpGX2vxxg1/sXX0G0WP+39ys2Ve 1220274099 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 918A47572; Mon, 1 Sep 2008 09:01:39 -0400 (EDT) Message-ID: <48BBE7B2.4050409@FreeBSD.org> Date: Mon, 01 Sep 2008 14:01:38 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.14 (X11/20080514) MIME-Version: 1.0 To: debarshi.ray@gmail.com References: <3170f42f0809010507q6c37a9d5q19649bc261d7656d@mail.gmail.com> In-Reply-To: <3170f42f0809010507q6c37a9d5q19649bc261d7656d@mail.gmail.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD networking and TCP/IP list Subject: Re: reading routing table 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, 01 Sep 2008 13:01:40 -0000 Debarshi Ray wrote: > ... > I was going through the FreeBSD and NetBSD documentation and the > FreeBSD sources of netstat and route. I was suprised to see that while > NetBSD's route implementation has a 'show' command, FreeBSD does not > offer any such thing. Moreover it seems that one can not read the > entire routing table using the PF_ROUTE sockets and RTM_GET returns > information pertaining to only one destination. This suprised me > because one can do such a thing with the Linux kernel's RTNETLINK. > > Is there a reason why this is so? Or is reading from /dev/kmem the > only way to get a dump of the routing tables? > You want 'netstat -rn' to dump them, this is a very common command which should be present in a number of online resources on using and administering FreeBSD so I am somewhat surprised that you didn't find it. P.S. Look in the sysctl tree if you need to snapshot the kernel IP forwarding tables. You can use kmem, but it is generally frowned upon unless you're working from core dumps -- kernels can be built without kmem support, or kmem locked down, etc. cheers BMS From owner-freebsd-net@FreeBSD.ORG Mon Sep 1 13:19:04 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 894C91065681 for ; Mon, 1 Sep 2008 13:19:04 +0000 (UTC) (envelope-from debarshi.ray@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by mx1.freebsd.org (Postfix) with ESMTP id 1DDD48FC1B for ; Mon, 1 Sep 2008 13:19:03 +0000 (UTC) (envelope-from debarshi.ray@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so1236652fgb.35 for ; Mon, 01 Sep 2008 06:19:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=p7btum86jM93eeF+EOXNQDk1nHmZfZoGCuYxarzm8rk=; b=PB/6k6PrJL53A70AdWxdmFkiM6FolT9duOyhKk+3mscyowDDsthiq3tsV8rsRg2uIE XqHWw5UxO77uIiU++8nzvW419buD7+De6X3MYpU05P5gPmZFH2gSahnWzoWwdDA8JI6Z +thl63WLBhgyZJI1SD+dpB5XGVIFzrIeoYeNI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:to:subject:cc:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:references; b=IYVyMgyWqwyDoBxEPgWTnfVGmTxqCz0ZVXiNI09aonvl60uli0wgzlqBIb7Iv1+dD0 QggdsyUfaT2/nLtiEwnck8lvCZAjYDVPJ8/yo5cpWZXqqkMekJQgqCabVUdJ4HSoj3sY Ql11xCrR5NT5pA8BqTvs/ae4mBG/VgdZqMlaA= Received: by 10.187.174.16 with SMTP id b16mr1933028fap.104.1220275142836; Mon, 01 Sep 2008 06:19:02 -0700 (PDT) Received: by 10.187.245.8 with HTTP; Mon, 1 Sep 2008 06:19:02 -0700 (PDT) Message-ID: <3170f42f0809010619i4d95318x7496e45a442c9654@mail.gmail.com> Date: Mon, 1 Sep 2008 18:49:02 +0530 From: "Debarshi Ray" To: "Bruce M. Simpson" In-Reply-To: <48BBE7B2.4050409@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3170f42f0809010507q6c37a9d5q19649bc261d7656d@mail.gmail.com> <48BBE7B2.4050409@FreeBSD.org> Cc: FreeBSD networking and TCP/IP list Subject: Re: reading routing table X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: debarshi.ray@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2008 13:19:04 -0000 > You want 'netstat -rn' to dump them, this is a very common command which > should be present in a number of online resources on using and administering > FreeBSD so I am somewhat surprised that you didn't find it. I know about netstat. I did mention having gone through its implementation. :-) What I am asking about is related to the implementation of the 'netstat -rn' functionality, which on some non-FreeBSD systems is also provided by 'route [show] -n'. > P.S. Look in the sysctl tree if you need to snapshot the kernel IP > forwarding tables. You can use kmem, but it is generally frowned upon unless > you're working from core dumps -- kernels can be built without kmem support, > or kmem locked down, etc. Ok, I will have a look. Thanks. Happy hacking, Debarshi From owner-freebsd-net@FreeBSD.ORG Mon Sep 1 13:29:49 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 712EB106564A for ; Mon, 1 Sep 2008 13:29:49 +0000 (UTC) (envelope-from debarshi.ray@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by mx1.freebsd.org (Postfix) with ESMTP id C02768FC18 for ; Mon, 1 Sep 2008 13:29:48 +0000 (UTC) (envelope-from debarshi.ray@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so1238934fgb.35 for ; Mon, 01 Sep 2008 06:29:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=B+GvBk/XGLAZkEnAiGmbbGIJ8nxflfu+I/5xteMJGu0=; b=agvAvg2ixoIvzsBvcaRzutIYfYJCmMV0nXJoqvT4LBPxDacnEfukCwj0zNIXIIeHsw ehK3rrfZrreAy4rHQBDVNIRLMsyZDHAdBKHKPe8Wvow6vMlvuz0PLcj7Dnwvgva+mi/a LdBZpHLymhG53xAE18R+tPOCuSJwOeZQFzVrU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:to:subject:cc:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:references; b=grB7JsTTYSTbeftNJ+fsbTfZAmNyelt8EABVl32Tdwjp123gT+JoUe0W1j1cPQgeaA r6YJdzKaR1WlgFYA3d6mUkWeOwSj7EqSIz/VuMfJi/WLKRDEc7wk+3T52ro8Wph1io2R 15O8u9s5MtNcOgubmr+JPZmautQmqvypcGyRs= Received: by 10.187.224.11 with SMTP id b11mr1932927far.16.1220275430009; Mon, 01 Sep 2008 06:23:50 -0700 (PDT) Received: by 10.187.245.8 with HTTP; Mon, 1 Sep 2008 06:23:49 -0700 (PDT) Message-ID: <3170f42f0809010623k1df25c18u7c784d4431e5a8ce@mail.gmail.com> Date: Mon, 1 Sep 2008 18:53:49 +0530 From: "Debarshi Ray" To: "Bruce M. Simpson" In-Reply-To: <48BBE5F2.4000108@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3170f42f0809010507q6c37a9d5q19649bc261d7656d@mail.gmail.com> <48BBE5F2.4000108@FreeBSD.org> Cc: FreeBSD networking and TCP/IP list Subject: Re: reading routing table X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: debarshi.ray@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2008 13:29:49 -0000 > Why don't you just use XORP's FEA code? > It already does all this under a BSD-type license. I was not aware of it. What does it do? Is it portable across other OSes or is it *BSD specific? Thanks, Debarshi From owner-freebsd-net@FreeBSD.ORG Mon Sep 1 13:34:28 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3544B106564A for ; Mon, 1 Sep 2008 13:34:28 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 0DEFE8FC16 for ; Mon, 1 Sep 2008 13:34:28 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id B44F115C2E0; Mon, 1 Sep 2008 09:34:27 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute2.internal (MEProxy); Mon, 01 Sep 2008 09:34:27 -0400 X-Sasl-enc: 2tqv1aB8DcXZu1jFJJrJrEvDRpQj6CoHGYH5xoA/HsN8 1220276067 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 443563971E; Mon, 1 Sep 2008 09:34:27 -0400 (EDT) Message-ID: <48BBEF62.3030000@FreeBSD.org> Date: Mon, 01 Sep 2008 14:34:26 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.14 (X11/20080514) MIME-Version: 1.0 To: debarshi.ray@gmail.com References: <3170f42f0809010507q6c37a9d5q19649bc261d7656d@mail.gmail.com> <48BBE5F2.4000108@FreeBSD.org> <3170f42f0809010623k1df25c18u7c784d4431e5a8ce@mail.gmail.com> In-Reply-To: <3170f42f0809010623k1df25c18u7c784d4431e5a8ce@mail.gmail.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD networking and TCP/IP list Subject: Re: reading routing table 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, 01 Sep 2008 13:34:28 -0000 Debarshi Ray wrote: >> Why don't you just use XORP's FEA code? >> It already does all this under a BSD-type license. >> > > I was not aware of it. What does it do? Is it portable across other > OSes or is it *BSD specific? > XORP's FEA process is responsible for talking to the underlying forwarding plane. It supports *BSD, Linux, MacOS X, and Microsoft Windows. Over the last year there was a refactoring where the forwarding table management got split into plugin-like modules. It is written in C++ although it's likely this split might make integration into other projects easier. Normally that support all goes into a single process, rather than being linked into many. cheers BMS From owner-freebsd-net@FreeBSD.ORG Mon Sep 1 13:37:51 2008 Return-Path: Delivered-To: net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D00E1065678; Mon, 1 Sep 2008 13:37:51 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 76D2B8FC16; Mon, 1 Sep 2008 13:37:51 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from freefall.freebsd.org (bms@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m81Dbp01086670; Mon, 1 Sep 2008 13:37:51 GMT (envelope-from bms@freefall.freebsd.org) Received: (from bms@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m81DbpNx086666; Mon, 1 Sep 2008 13:37:51 GMT (envelope-from bms) Date: Mon, 1 Sep 2008 13:37:51 GMT Message-Id: <200809011337.m81DbpNx086666@freefall.freebsd.org> To: bms@FreeBSD.org, bms@FreeBSD.org, net@FreeBSD.org From: bms@FreeBSD.org Cc: Subject: Re: docs/120945: [PATCH] ip6(4) man page lacks documentation for TCLASS option. 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, 01 Sep 2008 13:37:51 -0000 Synopsis: [PATCH] ip6(4) man page lacks documentation for TCLASS option. Responsible-Changed-From-To: bms->net Responsible-Changed-By: bms Responsible-Changed-When: Mon 1 Sep 2008 13:37:24 UTC Responsible-Changed-Why: Someone else best grab this until I learn how to MFC in Subversion. http://www.freebsd.org/cgi/query-pr.cgi?pr=120945 From owner-freebsd-net@FreeBSD.ORG Mon Sep 1 15:15:25 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F4F9106567A for ; Mon, 1 Sep 2008 15:15:25 +0000 (UTC) (envelope-from debarshi.ray@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by mx1.freebsd.org (Postfix) with ESMTP id A2C868FC24 for ; Mon, 1 Sep 2008 15:15:24 +0000 (UTC) (envelope-from debarshi.ray@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so1261447fgb.35 for ; Mon, 01 Sep 2008 08:15:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=8tOWCnQY57mulRbC069pJ4IvcaoVzswKOglUPZRJ3O0=; b=Pir7rCT8eFESHvOYMXByzgr1VsFSBA+bmc5gqpz0spcsB22pC06J5HaRVJtmyjOFUQ tgDbOkmeQUDqPSkbeWim7KyyhWmWjCaAxoQe7xpA6VdiTaigrL+dF5p7giD5dJxEa7We xXYTPqVI3a32Fgj+dor8rC2CMiIY297bDitFQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:to:subject:cc:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:references; b=JrmF/AkWMkBtDTbCz3LcK3mTUr9ZfWl9R4l85bg9MuA8hPGqQd+AYNXCPOrihAb468 0H9mLCqW0ltqGsL6vFZg1x8UFVuBIZZznulRwpK/I3FfKVwYtIXbgqs4Lr2MMVoFPHZv C4SRxK8Oh2F/XuwfFfm1rSG+hUuQ9VqKCYxIQ= Received: by 10.187.195.7 with SMTP id x7mr1945649fap.46.1220282123194; Mon, 01 Sep 2008 08:15:23 -0700 (PDT) Received: by 10.187.245.8 with HTTP; Mon, 1 Sep 2008 08:15:23 -0700 (PDT) Message-ID: <3170f42f0809010815q77f50bcat39e5bcd6563ecd7@mail.gmail.com> Date: Mon, 1 Sep 2008 20:45:23 +0530 From: "Debarshi Ray" To: "Bruce M. Simpson" In-Reply-To: <48BBE5F2.4000108@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3170f42f0809010507q6c37a9d5q19649bc261d7656d@mail.gmail.com> <48BBE5F2.4000108@FreeBSD.org> Cc: FreeBSD networking and TCP/IP list Subject: Re: reading routing table X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: debarshi.ray@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2008 15:15:25 -0000 > Why don't you just use XORP's FEA code? > It already does all this under a BSD-type license. Nice stuff. However, it looks like a full blown routing platform. In that case it would be easier to re-write those portions using the relevant set of APIs. Happy hacking, Debarshi From owner-freebsd-net@FreeBSD.ORG Tue Sep 2 07:00:53 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 281EF10656C0 for ; Tue, 2 Sep 2008 07:00:53 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outU.internet-mail-service.net (outu.internet-mail-service.net [216.240.47.244]) by mx1.freebsd.org (Postfix) with ESMTP id 0DBFE8FC14 for ; Tue, 2 Sep 2008 07:00:53 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id A52472423; Tue, 2 Sep 2008 00:00:52 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 6AFE52D603A; Tue, 2 Sep 2008 00:00:51 -0700 (PDT) Message-ID: <48BCE4AA.6050807@elischer.org> Date: Tue, 02 Sep 2008 00:00:58 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: "Bruce M. Simpson" References: <3170f42f0809010507q6c37a9d5q19649bc261d7656d@mail.gmail.com> <48BBE7B2.4050409@FreeBSD.org> In-Reply-To: <48BBE7B2.4050409@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: debarshi.ray@gmail.com, FreeBSD networking and TCP/IP list Subject: Re: reading routing table 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, 02 Sep 2008 07:00:53 -0000 Bruce M. Simpson wrote: > Debarshi Ray wrote: >> ... >> I was going through the FreeBSD and NetBSD documentation and the >> FreeBSD sources of netstat and route. I was suprised to see that while >> NetBSD's route implementation has a 'show' command, FreeBSD does not >> offer any such thing. Moreover it seems that one can not read the >> entire routing table using the PF_ROUTE sockets and RTM_GET returns >> information pertaining to only one destination. This suprised me >> because one can do such a thing with the Linux kernel's RTNETLINK. >> >> Is there a reason why this is so? Or is reading from /dev/kmem the >> only way to get a dump of the routing tables? >> > > You want 'netstat -rn' to dump them, this is a very common command which > should be present in a number of online resources on using and > administering FreeBSD so I am somewhat surprised that you didn't find it. > > P.S. Look in the sysctl tree if you need to snapshot the kernel IP > forwarding tables. You can use kmem, but it is generally frowned upon > unless you're working from core dumps -- kernels can be built without > kmem support, or kmem locked down, etc. unfortunatly netstat -rn uses /dev/kmem we've just never got around to implementing a better interface.. > > cheers > BMS > _______________________________________________ > 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 Sep 2 07:17:53 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4F33106566B for ; Tue, 2 Sep 2008 07:17:53 +0000 (UTC) (envelope-from debarshi.ray@gmail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.187]) by mx1.freebsd.org (Postfix) with ESMTP id 435688FC13 for ; Tue, 2 Sep 2008 07:17:52 +0000 (UTC) (envelope-from debarshi.ray@gmail.com) Received: by fk-out-0910.google.com with SMTP id k31so1890594fkk.11 for ; Tue, 02 Sep 2008 00:17:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=o9/+XI6x0cKcb2xBoUzia1c3HvdR2Rtp03dHr4W4O5Q=; b=mOGA/PP0wMM3KNfn+MSNz+uOk0UiQ5TX8yU+mU59txZqp3VnCyYHDIJ9/sOcpkU29L SUwK2crKcxWj3kkkmkv2ip2U4YI19VZ858DK8SDYUytYogywEBJYzd/J2sZDp+epPj/j M5bOTJ8KUG0/vK2j57sY9ndp+jzeN5zheEIWA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:to:subject:cc:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:references; b=sz2y1L3qXLmkVPpNDtG8A62kiV0vkNqodTDgweXVI8mLAP3APZnSrW0DCKuKqyJVz3 G1fIBJNGuboahsmRl+GAQjKXHBZ5xDQc19V886Co7wLJeda+pEZnoXgYKpZeZxF0GCU6 Me1oM4x696sa7c2NAN4CFQCqgkHhdL3fhgnPc= Received: by 10.187.182.10 with SMTP id j10mr2009755fap.39.1220339871811; Tue, 02 Sep 2008 00:17:51 -0700 (PDT) Received: by 10.187.245.8 with HTTP; Tue, 2 Sep 2008 00:17:51 -0700 (PDT) Message-ID: <3170f42f0809020017k643180efte155a5b5701a40cf@mail.gmail.com> Date: Tue, 2 Sep 2008 12:47:51 +0530 From: "Debarshi Ray" To: "Julian Elischer" In-Reply-To: <48BCE4AA.6050807@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3170f42f0809010507q6c37a9d5q19649bc261d7656d@mail.gmail.com> <48BBE7B2.4050409@FreeBSD.org> <48BCE4AA.6050807@elischer.org> Cc: FreeBSD networking and TCP/IP list , "Bruce M. Simpson" Subject: Re: reading routing table X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: debarshi.ray@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2008 07:17:53 -0000 > unfortunatly netstat -rn uses /dev/kmem Yes. I also found that FreeBSD's route(8) implementation does not have an equivalent of 'netstat -r'. NetBSD and GNU/Linux implementations have such an option. Any reason for this? Is it because you did not want to muck with /dev/kmem in route(8) and wanted it to work with PF_ROUTE only? I have not yet gone through NetBSD's route(8) code though. Happy hacking, Debarshi From owner-freebsd-net@FreeBSD.ORG Tue Sep 2 09:19:57 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E98F1065676 for ; Tue, 2 Sep 2008 09:19:57 +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 0CD228FC25 for ; Tue, 2 Sep 2008 09:19:56 +0000 (UTC) (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 1759F46C2A; Tue, 2 Sep 2008 05:19:55 -0400 (EDT) Date: Tue, 2 Sep 2008 10:19:55 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Debarshi Ray In-Reply-To: <3170f42f0809020017k643180efte155a5b5701a40cf@mail.gmail.com> Message-ID: References: <3170f42f0809010507q6c37a9d5q19649bc261d7656d@mail.gmail.com> <48BBE7B2.4050409@FreeBSD.org> <48BCE4AA.6050807@elischer.org> <3170f42f0809020017k643180efte155a5b5701a40cf@mail.gmail.com> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD networking and TCP/IP list , "Bruce M. Simpson" , Julian Elischer Subject: Re: reading routing table 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, 02 Sep 2008 09:19:57 -0000 On Tue, 2 Sep 2008, Debarshi Ray wrote: >> unfortunatly netstat -rn uses /dev/kmem > > Yes. I also found that FreeBSD's route(8) implementation does not have an > equivalent of 'netstat -r'. NetBSD and GNU/Linux implementations have such > an option. Any reason for this? Is it because you did not want to muck with > /dev/kmem in route(8) and wanted it to work with PF_ROUTE only? I have not > yet gone through NetBSD's route(8) code though. Usually the "reason" for things like this is that no one has written the code to do otherwise :-). PF_ROUTE is probably not a good mechanism for any bulk data transfer due to the constraints of being a datagram socket, although doing it via an interated dump rather than a simple dump operation would probably work. Sysctl is generally a better interface for monitoring for various reasona, although it also has limitations. Maintaining historic kmem support is important, since it is also the code used for interpreting core dumps, and we don't want to lose support for that. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-net@FreeBSD.ORG Tue Sep 2 10:48:34 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE5DE1065671 for ; Tue, 2 Sep 2008 10:48:34 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id 585958FC15 for ; Tue, 2 Sep 2008 10:48:34 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 9C0957309C; Tue, 2 Sep 2008 12:51:24 +0200 (CEST) Date: Tue, 2 Sep 2008 12:51:24 +0200 From: Luigi Rizzo To: FreeBSD networking and TCP/IP list Message-ID: <20080902105124.GA22832@onelab2.iet.unipi.it> References: <3170f42f0809010507q6c37a9d5q19649bc261d7656d@mail.gmail.com> <48BBE7B2.4050409@FreeBSD.org> <48BCE4AA.6050807@elischer.org> <3170f42f0809020017k643180efte155a5b5701a40cf@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Subject: how to read dynamic data structures from the kernel (was Re: reading routing table) 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, 02 Sep 2008 10:48:34 -0000 in the (short so far) thread which i am hijacking, the issue came out of what is a good mechanism for reading the route table from the kernel, since FreeBSD currently uses /dev/kmem and this is not always available/easy to use with dynamically changing data structures. The routing table is only one instance of potentially many similar data structures that we might want to fetch - others are the various firewall tables (the output of 'ipfw show'), possibly bridging tables, socket lists and so on. The issue is actually twofold. The interface problem, or how to pull bits from the kernel, is so easy to be almost irrelevant -- getsockopt, sysctl, kmem, or some special file descriptor does the job as long as the underlying chunk of data does not change (or can be locked) during the syscall. The real problem is that these data structures are dynamic and potentially large, so the following approach (used e.g. in ipfw) enter kernel; get shared lock on the structure; navigate through the structure and make a linearized copy; unlock; copyout the linearized copy; is extremely expensive and has the potential to block other activities for a long time. Accessing /dev/kmem and follow pointers there has probably the risk that you cannot lock the kernel data structure while you navigate on it, so you are likely to follow stale pointers. What we'd need is some internal representation of the data structure that could give us individual entries of the data structure on each call, together with extra info (a pointer if we can guarantee that it doesn't get stale, something more if we cannot make the guarantee) to allow the navigation to occur. I believe this is a very old and common problem, so my question is: do you know if any of the *BSD kernels implements some good mechanism to access a dynamic kernel data structure (e.g. the routing tree/trie, or even a list or hash table) without the flaws of the two approaches i indicate above ? cheers luigi [original thread below just for reference, but i believe i made a fair summary above] On Tue, Sep 02, 2008 at 10:19:55AM +0100, Robert Watson wrote: > On Tue, 2 Sep 2008, Debarshi Ray wrote: > > >>unfortunatly netstat -rn uses /dev/kmem > > > >Yes. I also found that FreeBSD's route(8) implementation does not have an > >equivalent of 'netstat -r'. NetBSD and GNU/Linux implementations have such > >an option. Any reason for this? Is it because you did not want to muck > >with /dev/kmem in route(8) and wanted it to work with PF_ROUTE only? I > >have not yet gone through NetBSD's route(8) code though. > > Usually the "reason" for things like this is that no one has written the > code to do otherwise :-). PF_ROUTE is probably not a good mechanism for > any bulk data transfer due to the constraints of being a datagram socket, > although doing it via an interated dump rather than a simple dump operation > would probably work. Sysctl is generally a better interface for monitoring > for various reasona, although it also has limitations. Maintaining > historic kmem support is important, since it is also the code used for > interpreting core dumps, and we don't want to lose support for that. > > Robert N M Watson > Computer Laboratory > University of Cambridge > _______________________________________________ > 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 Sep 2 14:55:56 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F6361065681 for ; Tue, 2 Sep 2008 14:55:56 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by mx1.freebsd.org (Postfix) with ESMTP id C51E88FC08 for ; Tue, 2 Sep 2008 14:55:55 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 0E29815B987; Tue, 2 Sep 2008 10:55:55 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute2.internal (MEProxy); Tue, 02 Sep 2008 10:55:55 -0400 X-Sasl-enc: L8Uj39Rt4N3sCc1VHExaZxMd7ZIz6kLpePJmSkDJ1FFs 1220367354 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 7E71C3BC71; Tue, 2 Sep 2008 10:55:54 -0400 (EDT) Message-ID: <48BD53F9.50002@FreeBSD.org> Date: Tue, 02 Sep 2008 15:55:53 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.14 (X11/20080514) MIME-Version: 1.0 To: Luigi Rizzo References: <3170f42f0809010507q6c37a9d5q19649bc261d7656d@mail.gmail.com> <48BBE7B2.4050409@FreeBSD.org> <48BCE4AA.6050807@elischer.org> <3170f42f0809020017k643180efte155a5b5701a40cf@mail.gmail.com> <20080902105124.GA22832@onelab2.iet.unipi.it> In-Reply-To: <20080902105124.GA22832@onelab2.iet.unipi.it> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD networking and TCP/IP list Subject: Re: how to read dynamic data structures from the kernel (was Re: reading routing table) 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, 02 Sep 2008 14:55:56 -0000 Luigi Rizzo wrote: > do you know if any of the *BSD kernels implements some good mechanism > to access a dynamic kernel data structure (e.g. the routing tree/trie, > or even a list or hash table) without the flaws of the two approaches > i indicate above ? > Hahaha. I ran into an isomorphic problem with Net-SNMP at work last week. There's a need to export the BGP routing table via SNMP. Of course doing this in our framework at work requires some IPC calls which always require a select() (or WaitForMultipleObjects()) based continuation. Net-SNMP doesn't support continuations at the table iterator level, so somehow, we need to implement an iterator which can accomodate our blocking IPC mechanism. [No, we don't use threads, and that would actually create more problems than it solves -- running single-threaded with continuations lets us run lock free, and we rely on the OS's IPC primitives to serialize our code. works just fine for us so far...] So we would end up caching the whole primary key range in the SNMP sub-agent on a table OID access, a technique which would allow us to defer the IPC calls providing we walk the entire range of the iterator and cache the keys -- but even THAT is far too much data for the BGP table, which is a trie with ~250,000 entries. I hate SNMP GETNEXT. Back to the FreeBSD kernel, though. If you look at in_mcast.c, particularly in p4 bms_netdev, this is what happens for the per-socket multicast source filters -- there is the linearization of an RB-tree for setsourcefilter(). This is fine for something with a limit of ~256 entries per socket (why RB for something so small? this is for space vs time -- and also it has to merge into a larger filter list in the IGMPv3 paths.) And the lock granularity is per-socket. However it doesn't do for something as big as a BGP routing table. C++ lends itself well to expressing these kinds of smart-pointer idioms, though. I'm thinking perhaps we need the notion of a sysctl iterator, which allocates a token for walking a shared data structure, and is able to guarantee that the token maps to a valid pointer for the same entry, until its 'advance pointer' operation is called. Question is, who's going to pull the trigger? cheers BMS P.S. I'm REALLY getting fed up with the lack of openness and transparency largely incumbent in doing work in p4. Come one come all -- we shouldn't need accounts for folk to see and contribute what's going on, and the stagnation is getting silly. FreeBSD development should not be a committer or chum-of-committer in-crowd. From owner-freebsd-net@FreeBSD.ORG Tue Sep 2 16:40:19 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55347106567E; Tue, 2 Sep 2008 16:40:19 +0000 (UTC) (envelope-from jgreco@aurora.sol.net) Received: from mail1.sol.net (mail1.sol.net [206.55.64.72]) by mx1.freebsd.org (Postfix) with ESMTP id ED8CD8FC13; Tue, 2 Sep 2008 16:40:18 +0000 (UTC) (envelope-from jgreco@aurora.sol.net) Received: from aurora.sol.net (aurora.sol.net [206.55.65.130]) by mail1.sol.net (8.14.1/8.14.1/SNNS-1.04) with ESMTP id m82FgNHa031767; Tue, 2 Sep 2008 10:42:23 -0500 (CDT) Received: (from jgreco@localhost) by aurora.sol.net (8.12.8p1/8.12.9/Submit) id m82Fg9GK087484; Tue, 2 Sep 2008 10:42:09 -0500 (CDT) From: Joe Greco Message-Id: <200809021542.m82Fg9GK087484@aurora.sol.net> To: eugen@kuzbass.ru, freebsd-net@freebsd.org, jlin2918@yahoo.com Date: Tue, 2 Sep 2008 10:42:09 -0500 (CDT) X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: bms@freebsd.org Subject: Re: Quagga OSPF binds to wrong interface on FreeBSD 7 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, 02 Sep 2008 16:40:19 -0000 Joining this conversation as someone who's been wrestling with this issue for some months: > > This bug was reported around the release of FreeBSD 7, but does not seem > > to have made any progress. > > > > http://bugzilla.quagga.net/show_bug.cgi?id=420 > > > > Is this because the sockopt.c.diff patch is correct, which isn't entirely > > clear from the following comments, or is there some other solution to this > > problem? Thanks! > > You should contact with ports/net/quagga maintainer to push > temporary patch into Ports Tree until quagga developers settle with > something working. This always was most productive way for us. I've been doing extremely limited testing on the sockopt.c patch, on a 7.0R box that used to have problems, and it "seems to" work. However, the failures we were noticing seemed most frequent and catastrophic when using a 7.0R box as a router with about a dozen interfaces active (we got instant failures, in many/most/all?? cases). I don't have a lab setup capable of reproducing this at the moment, and am not willing to sacrifice production networks to the "well just try it and see" patch testing god. I believe the question that was asked is not the question you answered. I, too, would like someone who can offer a knowledgeable opinion as to the correctness of the patch. Were someone who has worked on the code, such as Bruce, to tell me that it appeared to be the right solution, I would be willing to risk a test on a 7.0R box known to fall over rapidly with the multicast issue. I am certainly interested in seeing this fixed. Until someone can either test the heck out of this, or offer a definitive opinion of the correctness based on experience with this subsystem, it would seem premature to ask the port maintainer to include a patch of dubious correctness. I have cc:'d bms@ in the hopes of bringing in such an opinion. I am not sure who else is working on the multicast subsystem at this time, but hopefully someone else can input if appropriate. Knowing that the patch was correct would also provide some leverage for those of us with interest in this code to persuade the Quagga developers to do something about this. As it is, we're left here holding a bag of "this patch is supposed to work but we don't really know it is correct." So it would be really useful to have such an opinion. Thanks, ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From owner-freebsd-net@FreeBSD.ORG Tue Sep 2 17:03:28 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1F87106567B for ; Tue, 2 Sep 2008 17:03:28 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by mx1.freebsd.org (Postfix) with ESMTP id 8CA548FC08 for ; Tue, 2 Sep 2008 17:03:28 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 0CD8015BF39; Tue, 2 Sep 2008 13:03:28 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Tue, 02 Sep 2008 13:03:28 -0400 X-Sasl-enc: 3kQ33bHWLWDox61huzFAsmvMFYPicumGsXqlyi2VBsti 1220375007 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id EA2091365C; Tue, 2 Sep 2008 13:03:26 -0400 (EDT) Message-ID: <48BD71DD.10707@FreeBSD.org> Date: Tue, 02 Sep 2008 18:03:25 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.14 (X11/20080514) MIME-Version: 1.0 To: Joe Greco References: <200809021542.m82Fg9GK087484@aurora.sol.net> In-Reply-To: <200809021542.m82Fg9GK087484@aurora.sol.net> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: jlin2918@yahoo.com, freebsd-net@freebsd.org, eugen@kuzbass.ru Subject: Re: Quagga OSPF binds to wrong interface on FreeBSD 7 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, 02 Sep 2008 17:03:28 -0000 Joe Greco wrote: > ... > Knowing that the patch was correct would also provide some leverage for > those of us with interest in this code to persuade the Quagga developers > to do something about this. As it is, we're left here holding a bag of > "this patch is supposed to work but we don't really know it is correct." > So it would be really useful to have such an opinion. > I understand that this situation has dragged on for some 18 months since changes went into 7.x. I'm sorry to hear about the problems you're having. I can't speak for Quagga as I haven't worked on it in many years, nor can I speak for the Quagga patch. On the other hand: there's a published RFC for the SSM multicast API, there has been Linux support for this API for quite some time, and at least one major commercial deployment of it (Microsoft Windows). What's the real problem here? cheers BMS From owner-freebsd-net@FreeBSD.ORG Tue Sep 2 21:02:11 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1504106568F for ; Tue, 2 Sep 2008 21:02:11 +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 B96578FC17 for ; Tue, 2 Sep 2008 21:02:11 +0000 (UTC) (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 96D0046C3E; Tue, 2 Sep 2008 17:02:09 -0400 (EDT) Date: Tue, 2 Sep 2008 22:02:10 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Luigi Rizzo In-Reply-To: <20080902105124.GA22832@onelab2.iet.unipi.it> Message-ID: References: <3170f42f0809010507q6c37a9d5q19649bc261d7656d@mail.gmail.com> <48BBE7B2.4050409@FreeBSD.org> <48BCE4AA.6050807@elischer.org> <3170f42f0809020017k643180efte155a5b5701a40cf@mail.gmail.com> <20080902105124.GA22832@onelab2.iet.unipi.it> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD networking and TCP/IP list Subject: Re: how to read dynamic data structures from the kernel (was Re: reading routing table) 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, 02 Sep 2008 21:02:12 -0000 On Tue, 2 Sep 2008, Luigi Rizzo wrote: > The real problem is that these data structures are dynamic and potentially > large, so the following approach (used e.g. in ipfw) > > enter kernel; > get shared lock on the structure; > navigate through the structure and make a linearized copy; > unlock; > copyout the linearized copy; > > is extremely expensive and has the potential to block other activities for a > long time. Sockets, sysctl, kmem, etc, are all really just I/O mechanisms, with varying levels of abstraction, for pushing data, and all fundamentally suffer from the problem of a lack of general export abstraction. > What we'd need is some internal representation of the data structure that > could give us individual entries of the data structure on each call, > together with extra info (a pointer if we can guarantee that it doesn't get > stale, something more if we cannot make the guarantee) to allow the > navigation to occur. I think there's necessarily implementation-specific details to all of these steps for any given kernel subsystem -- we have data structures, synchronization models, etc, that are all tuned to their common use requirements, and monitoring is very much an edge case. I don't think this is bad: this is an OS kernel, after all, but it does make things a bit more tricky. Even if we can't share code, sharing approaches across subsystems is a good idea. For an example of what you have in mind, take a look at the sysctl monitoring for UNIX domain sockets. First, we allocate an array of pointers sized to the number of unpcb's we have. Then we walk the list, bumping the references and adding pointers to the array. Then we release the global locks, and proceed lock, externalize, unlock, and copyout each individual entry, using a generation number fo manage staleness. Finally, we walk the list dropping the refcounts and free the array. This voids holding global locks for a long time, as well as the stale data issue. It's unideal in other ways -- long lists, reference count complexity, etc, but as I mentioned, it is very much an edge case, and much of that mechanism (especially refcounts) is something we need anyway for any moderately complex kernel data structure. Robert N M Watson Computer Laboratory University of Cambridge > Accessing /dev/kmem and follow pointers there has probably the risk > that you cannot lock the kernel data structure while you navigate > on it, so you are likely to follow stale pointers. > > I believe this is a very old and common problem, so my question is: > > do you know if any of the *BSD kernels implements some good mechanism > to access a dynamic kernel data structure (e.g. the routing tree/trie, > or even a list or hash table) without the flaws of the two approaches > i indicate above ? > > cheers > luigi > > [original thread below just for reference, but i believe i made a > fair summary above] > > On Tue, Sep 02, 2008 at 10:19:55AM +0100, Robert Watson wrote: >> On Tue, 2 Sep 2008, Debarshi Ray wrote: >> >>>> unfortunatly netstat -rn uses /dev/kmem >>> >>> Yes. I also found that FreeBSD's route(8) implementation does not have an >>> equivalent of 'netstat -r'. NetBSD and GNU/Linux implementations have such >>> an option. Any reason for this? Is it because you did not want to muck >>> with /dev/kmem in route(8) and wanted it to work with PF_ROUTE only? I >>> have not yet gone through NetBSD's route(8) code though. >> >> Usually the "reason" for things like this is that no one has written the >> code to do otherwise :-). PF_ROUTE is probably not a good mechanism for >> any bulk data transfer due to the constraints of being a datagram socket, >> although doing it via an interated dump rather than a simple dump operation >> would probably work. Sysctl is generally a better interface for monitoring >> for various reasona, although it also has limitations. Maintaining >> historic kmem support is important, since it is also the code used for >> interpreting core dumps, and we don't want to lose support for that. >> >> Robert N M Watson >> Computer Laboratory >> University of Cambridge >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Tue Sep 2 21:28:27 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 195EF106566C; Tue, 2 Sep 2008 21:28:27 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id 9512E8FC20; Tue, 2 Sep 2008 21:28:26 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id BB96D73098; Tue, 2 Sep 2008 23:31:18 +0200 (CEST) Date: Tue, 2 Sep 2008 23:31:18 +0200 From: Luigi Rizzo To: Robert Watson Message-ID: <20080902213118.GB28398@onelab2.iet.unipi.it> References: <3170f42f0809010507q6c37a9d5q19649bc261d7656d@mail.gmail.com> <48BBE7B2.4050409@FreeBSD.org> <48BCE4AA.6050807@elischer.org> <3170f42f0809020017k643180efte155a5b5701a40cf@mail.gmail.com> <20080902105124.GA22832@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: FreeBSD networking and TCP/IP list Subject: Re: how to read dynamic data structures from the kernel (was Re: reading routing table) 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, 02 Sep 2008 21:28:27 -0000 On Tue, Sep 02, 2008 at 10:02:10PM +0100, Robert Watson wrote: > > On Tue, 2 Sep 2008, Luigi Rizzo wrote: > > >The real problem is that these data structures are dynamic and potentially > >large, so the following approach (used e.g. in ipfw) > > > > enter kernel; > > get shared lock on the structure; > > navigate through the structure and make a linearized copy; > > unlock; > > copyout the linearized copy; > > > >is extremely expensive and has the potential to block other activities for > >a long time. > > Sockets, sysctl, kmem, etc, are all really just I/O mechanisms, with > varying levels of abstraction, for pushing data, and all fundamentally > suffer from the problem of a lack of general export abstraction. yes, this is why i said we should not bother about which one is used. > >What we'd need is some internal representation of the data structure that > >could give us individual entries of the data structure on each call, > >together with extra info (a pointer if we can guarantee that it doesn't > >get stale, something more if we cannot make the guarantee) to allow the > >navigation to occur. > > I think there's necessarily implementation-specific details to all of these > steps for any given kernel subsystem -- we have data structures, > synchronization models, etc, that are all tuned to their common use > requirements, and monitoring is very much an edge case. I don't think this > is bad: this is an OS kernel, after all, but it does make things a bit more > tricky. Even if we can't share code, sharing approaches across subsystems > is a good idea. > > For an example of what you have in mind, take a look at the sysctl > monitoring for UNIX domain sockets. First, we allocate an array of > pointers sized to the number of unpcb's we have. Then we walk the list, > bumping the references and adding pointers to the array. Then we release > the global locks, and proceed lock, externalize, unlock, and copyout each > individual entry, using a generation number fo manage staleness. Finally, > we walk the list dropping the refcounts and free the array. This voids > holding global locks for a long time, as well as the stale data issue. > It's unideal in other ways -- long lists, reference count complexity, etc, > but as I mentioned, it is very much an edge case, and much of that > mechanism (especially refcounts) is something we need anyway for any > moderately complex kernel data structure. what you describe above is more efficient but not that different from what i described. The thing is, i always forget that in many cases an iterator doesn't care for the order in which elements are generated so you could use a solution like the one below, by just doing a tiny little bit of work while modifying the main data structure (this might well be a known solution, since it is so trivial...) [i already emailed the following to BMS, so apologies for the duplicate] if all you care is iterating the whole data structure, without a particular order, you could manage an additional array of pointers to all the objects in the data structure (the array should be implemented as a sparse, resizable array but that's a separate issue, and probably a relatively trivial one -- i am googling for it...). Navigation and iterators are simple: + When inserting a new element, append an entry to the array, and make it point to the newly added record. Each entry gets a fresh sequence numbers, and one should make sure that seqnumbers are not recycled (64 bit should suffice ?). + when deleting an element, logically remove the entry from the array + the iterator returns a copy of the object, and its sequence number; + getnext returns the existing element following the 'current' one in the sparse array. Complexity for most ops (data insertion, removal, lookup) would be O(1) plus whatever is needed to do housekeeping on the sparse array, and this depends on the usage of the main data structure and how much we worry for expensive 'getnext' ops. Sure you need a read lock on the main struct while you lookup the next element on the sparse array, but the nice thing is that you can release the lock at each step even if you have a poorly implemented sparse array. Makes sense ? cheers luigi From owner-freebsd-net@FreeBSD.ORG Tue Sep 2 22:08:14 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37F6C10656B8 for ; Tue, 2 Sep 2008 22:08:14 +0000 (UTC) (envelope-from stellan.alm@home.se) Received: from ch-smtp02.sth.basefarm.net (ch-smtp02.sth.basefarm.net [80.76.149.213]) by mx1.freebsd.org (Postfix) with ESMTP id C2F9C8FC22 for ; Tue, 2 Sep 2008 22:08:13 +0000 (UTC) (envelope-from stellan.alm@home.se) Received: from c213-89-76-218.bredband.comhem.se ([213.89.76.218]:59061 helo=[192.168.2.122]) by ch-smtp02.sth.basefarm.net with esmtp (Exim 4.68) (envelope-from ) id 1Kado6-0004Tz-9U for freebsd-net@freebsd.org; Tue, 02 Sep 2008 23:53:03 +0200 From: stellan alm To: freebsd-net@freebsd.org Content-Type: text/plain Date: Tue, 02 Sep 2008 23:53:00 +0200 Message-Id: <1220392380.3934.10.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Originating-IP: 213.89.76.218 X-Scan-Result: No virus found in message 1Kado6-0004Tz-9U. X-Scan-Signature: ch-smtp02.sth.basefarm.net 1Kado6-0004Tz-9U d52d3d3b61aa2f82a0279c7ef81ead4b Subject: avahi-daemon, Segmentation fault: 11 (core dumped) 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, 02 Sep 2008 22:08:14 -0000 Hi, Running: FreeBSD black 7.0-RELEASE-p2 FreeBSD 7.0-RELEASE-p2 #0: Wed Jun 18 07:33:20 UTC 2008 root@i386-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC i386 All the latest ports gnome2 and xfce4, output from gdb analysing the core says: ----------------------8<------------------------- $ gdb -c avahi-daemon.core /usr/local/sbin/avahi-daemon GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"...(no debugging symbols found)... Core was generated by `avahi-daemon'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/local/lib/libavahi-common.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libavahi-common.so.3 Reading symbols from /usr/local/lib/libavahi-core.so.5...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libavahi-core.so.5 Reading symbols from /usr/local/lib/libdaemon.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libdaemon.so.0 Reading symbols from /usr/local/lib/libexpat.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libexpat.so.6 Reading symbols from /usr/local/lib/libdbus-1.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libdbus-1.so.3 Reading symbols from /lib/libssp.so.0...(no debugging symbols found)...done. Loaded symbols for /lib/libssp.so.0 Reading symbols from /usr/local/lib/libintl.so.8...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libintl.so.8 Reading symbols from /usr/local/lib/libiconv.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libiconv.so.3 Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x280a73f9 in _thr_cancel_enter () from /usr/local/lib/libavahi-common.so.3 [New LWP 100162] (gdb) ----------------------8<------------------------- net/avahi is compiled with: $ less /var/db/ports/avahi/options # This file is auto-generated by 'make config'. # No user-servicable parts inside! # Options for avahi-0.6.23 _OPTIONS_READ=avahi-0.6.23 WITH_AUTOIPD=true WITH_GTK=true WITH_LIBDNS=true WITHOUT_MONO=true WITHOUT_QT3=true WITHOUT_QT4=true WITH_PYTHON=true Searching the net doesn't come up with anything... Removed all ports! Reinstalled but without luck. Kind regards, Stellan Alm From owner-freebsd-net@FreeBSD.ORG Tue Sep 2 22:10:19 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 76028106567B for ; Tue, 2 Sep 2008 22:10:19 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outX.internet-mail-service.net (outx.internet-mail-service.net [216.240.47.247]) by mx1.freebsd.org (Postfix) with ESMTP id 58DE98FC35 for ; Tue, 2 Sep 2008 22:10:19 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id F2C87247F; Tue, 2 Sep 2008 15:10:18 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 386B92D6025; Tue, 2 Sep 2008 15:10:18 -0700 (PDT) Message-ID: <48BDB9D0.9030108@elischer.org> Date: Tue, 02 Sep 2008 15:10:24 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Robert Watson References: <3170f42f0809010507q6c37a9d5q19649bc261d7656d@mail.gmail.com> <48BBE7B2.4050409@FreeBSD.org> <48BCE4AA.6050807@elischer.org> <3170f42f0809020017k643180efte155a5b5701a40cf@mail.gmail.com> <20080902105124.GA22832@onelab2.iet.unipi.it> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD networking and TCP/IP list , Luigi Rizzo Subject: Re: how to read dynamic data structures from the kernel (was Re: reading routing table) 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, 02 Sep 2008 22:10:19 -0000 Robert Watson wrote: > > On Tue, 2 Sep 2008, Luigi Rizzo wrote: > >> The real problem is that these data structures are dynamic and >> potentially large, so the following approach (used e.g. in ipfw) >> >> enter kernel; >> get shared lock on the structure; >> navigate through the structure and make a linearized copy; >> unlock; >> copyout the linearized copy; >> >> is extremely expensive and has the potential to block other activities >> for a long time. > > Sockets, sysctl, kmem, etc, are all really just I/O mechanisms, with > varying levels of abstraction, for pushing data, and all fundamentally > suffer from the problem of a lack of general export abstraction. > >> What we'd need is some internal representation of the data structure >> that could give us individual entries of the data structure on each >> call, together with extra info (a pointer if we can guarantee that it >> doesn't get stale, something more if we cannot make the guarantee) to >> allow the navigation to occur. > In some code I have seen (and some I have written) there is always two levels of storage in some modules.. One that contains the majority of the information and one that contains "changes that occured since the main container was locked".. so for example the routing tables might be locked and if a routing change is requested thereafter, it gets stored in a transactional form on the side structure.. a routing lookup during the period that the structure is locked (if a read lock) simply goes ahead, and at completion checks if there is a better answer in the waiting list. A write request is stored as a transaction request on the waiting list. not saying it works for everything but If we had a kernel written in a high enough level language, such methods could be broadly used.. oh well. using reader-writer locking mitigates a lot of this.. > I think there's necessarily implementation-specific details to all of > these steps for any given kernel subsystem -- we have data structures, > synchronization models, etc, that are all tuned to their common use > requirements, and monitoring is very much an edge case. I don't think > this is bad: this is an OS kernel, after all, but it does make things a > bit more tricky. Even if we can't share code, sharing approaches across > subsystems is a good idea. > > For an example of what you have in mind, take a look at the sysctl > monitoring for UNIX domain sockets. First, we allocate an array of > pointers sized to the number of unpcb's we have. Then we walk the list, > bumping the references and adding pointers to the array. Then we > release the global locks, and proceed lock, externalize, unlock, and > copyout each individual entry, using a generation number fo manage > staleness. Finally, we walk the list dropping the refcounts and free > the array. This voids holding global locks for a long time, as well as > the stale data issue. It's unideal in other ways -- long lists, > reference count complexity, etc, but as I mentioned, it is very much an > edge case, and much of that mechanism (especially refcounts) is > something we need anyway for any moderately complex kernel data structure. refcounts are, unfortunatly a really bad thing for multiprocessors. refcounts, if they are actually incremented now and then are usually out of scope for any given CPU forcing lots of cache flushes and real reads from memory. There are some elaborate MP-refcount schemes we really should look at but most require a lot of memory. > From owner-freebsd-net@FreeBSD.ORG Tue Sep 2 22:37:43 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F0BED1065671; Tue, 2 Sep 2008 22:37:43 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C99938FC08; Tue, 2 Sep 2008 22:37:43 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m82MbhC0099223; Tue, 2 Sep 2008 22:37:43 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m82MbhIx099219; Tue, 2 Sep 2008 22:37:43 GMT (envelope-from linimon) Date: Tue, 2 Sep 2008 22:37:43 GMT Message-Id: <200809022237.m82MbhIx099219@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/127050: [carp] ipv6 does not work on carp interfaces [regression] 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, 02 Sep 2008 22:37:44 -0000 Old Synopsis: ipv6 does not work on carp interfaces New Synopsis: [carp] ipv6 does not work on carp interfaces [regression] Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Tue Sep 2 22:37:07 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=127050 From owner-freebsd-net@FreeBSD.ORG Tue Sep 2 22:46:38 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8DFDA106568A; Tue, 2 Sep 2008 22:46:38 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 65A348FC1A; Tue, 2 Sep 2008 22:46:38 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m82MkcCV099640; Tue, 2 Sep 2008 22:46:38 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m82MkcdC099636; Tue, 2 Sep 2008 22:46:38 GMT (envelope-from linimon) Date: Tue, 2 Sep 2008 22:46:38 GMT Message-Id: <200809022246.m82MkcdC099636@freefall.freebsd.org> To: rea-fbsd@codelabs.ru, linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/127052: [if_bridge] Still bridge issues - with L2 protocols such as PPPoE 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, 02 Sep 2008 22:46:38 -0000 Old Synopsis: Still bridge issues - with L2 protocols such as PPPoE New Synopsis: [if_bridge] Still bridge issues - with L2 protocols such as PPPoE Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Tue Sep 2 22:46:19 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=127052 From owner-freebsd-net@FreeBSD.ORG Wed Sep 3 03:19:32 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A77CA106564A; Wed, 3 Sep 2008 03:19:32 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8134F8FC18; Wed, 3 Sep 2008 03:19:32 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m833JWWG072063; Wed, 3 Sep 2008 03:19:32 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m833JWQx072059; Wed, 3 Sep 2008 03:19:32 GMT (envelope-from linimon) Date: Wed, 3 Sep 2008 03:19:32 GMT Message-Id: <200809030319.m833JWQx072059@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/127057: [udp] Unable to send UDP packet via IPv6 socket to IPv4 mapped address 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, 03 Sep 2008 03:19:32 -0000 Old Synopsis: Unable to send UDP packet via IPv6 socket to IPv4 mapped address New Synopsis: [udp] Unable to send UDP packet via IPv6 socket to IPv4 mapped address Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Sep 3 03:18:48 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=127057 From owner-freebsd-net@FreeBSD.ORG Wed Sep 3 04:30:04 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 96D1B106566B for ; Wed, 3 Sep 2008 04:30:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8778F8FC17 for ; Wed, 3 Sep 2008 04:30:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m834U4OS077862 for ; Wed, 3 Sep 2008 04:30:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m834U4DM077859; Wed, 3 Sep 2008 04:30:04 GMT (envelope-from gnats) Date: Wed, 3 Sep 2008 04:30:04 GMT Message-Id: <200809030430.m834U4DM077859@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Eygene Ryabinkin Cc: Subject: Re: kern/127052: Still bridge issues - with L2 protocols such as PPPoE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Eygene Ryabinkin List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2008 04:30:04 -0000 The following reply was made to PR kern/127052; it has been noted by GNATS. From: Eygene Ryabinkin To: Helge Oldach Cc: bug-followup@FreeBSD.org, philip@FreeBSD.org Subject: Re: kern/127052: Still bridge issues - with L2 protocols such as PPPoE Date: Wed, 3 Sep 2008 08:21:43 +0400 --UNifc18z8z6e1QHx Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Tue, Sep 02, 2008 at 11:06:47PM +0200, Helge Oldach wrote: > Eygene supplied a patch that supposedly fixes this issue by introducing > a sysctl that makes the former if_bridge behaviour default, and which > must be turned on to enable MAC inheritance. I have not tested this > patch yet. And here is the patch itself: --- if_bridge-mac_inheritance.patch begins here --- =46rom 545d95995bb1879a6807be28a43d4ee061dda218 Mon Sep 17 00:00:00 2001 =46rom: Eygene Ryabinkin Date: Tue, 2 Sep 2008 19:49:44 +0400 Subject: [PATCH] Add sysctl net.link.bridge.inherit_mac to control MAC inhe= ritance Philip Paeps enabled bridge to inherit its MAC from the first bridge member. This broke ARP, it was fixed, but then Helge Oldach reported that this also brokes PPPoE when it is done on the bridged interface. I had implemented new sysctl that controls MAC inheritance. It is off by default to enable previous behaviour of bridge until all problems with duplicated MAC addresses will be chased and fixed. Signed-off-by: Eygene Ryabinkin --- sys/net/if_bridge.c | 9 +++++++-- 1 files changed, 7 insertions(+), 2 deletions(-) diff --git a/sys/net/if_bridge.c b/sys/net/if_bridge.c index a84a0ff..aee7c4a 100644 --- a/sys/net/if_bridge.c +++ b/sys/net/if_bridge.c @@ -350,6 +350,7 @@ static int pfil_ipfw_arp =3D 0; /* layer2 filter with= ipfw */ static int pfil_local_phys =3D 0; /* run pfil hooks on the physical interf= ace for locally destined packets */ static int log_stp =3D 0; /* log STP state changes */ +static int bridge_inherit_mac =3D 0; /* share MAC with first bridge memb= er */ SYSCTL_INT(_net_link_bridge, OID_AUTO, pfil_onlyip, CTLFLAG_RW, &pfil_onlyip, 0, "Only pass IP packets when pfil is enabled"); SYSCTL_INT(_net_link_bridge, OID_AUTO, ipfw_arp, CTLFLAG_RW, @@ -363,6 +364,9 @@ SYSCTL_INT(_net_link_bridge, OID_AUTO, pfil_local_phys,= CTLFLAG_RW, "Packet filter on the physical interface for locally destined packets"= ); SYSCTL_INT(_net_link_bridge, OID_AUTO, log_stp, CTLFLAG_RW, &log_stp, 0, "Log STP state changes"); +SYSCTL_INT(_net_link_bridge, OID_AUTO, inherit_mac, CTLFLAG_RW, + &bridge_inherit_mac, 0, + "Inherit MAC address from the first bridge member"); =20 struct bridge_control { int (*bc_func)(struct bridge_softc *, void *); @@ -921,7 +925,8 @@ bridge_delete_member(struct bridge_softc *sc, struct br= idge_iflist *bif, * the mac address of the bridge to the address of the next member, or * to its default address if no members are left. */ - if (!memcmp(IF_LLADDR(sc->sc_ifp), IF_LLADDR(ifs), ETHER_ADDR_LEN)) { + if (bridge_inherit_mac && + !memcmp(IF_LLADDR(sc->sc_ifp), IF_LLADDR(ifs), ETHER_ADDR_LEN)) { if (LIST_EMPTY(&sc->sc_iflist)) bcopy(sc->sc_defaddr, IF_LLADDR(sc->sc_ifp), ETHER_ADDR_LEN); @@ -1028,7 +1033,7 @@ bridge_ioctl_add(struct bridge_softc *sc, void *arg) * member and the MAC address of the bridge has not been changed from * the default randomly generated one. */ - if (LIST_EMPTY(&sc->sc_iflist) && + if (bridge_inherit_mac && LIST_EMPTY(&sc->sc_iflist) && !memcmp(IF_LLADDR(sc->sc_ifp), sc->sc_defaddr, ETHER_ADDR_LEN)) bcopy(IF_LLADDR(ifs), IF_LLADDR(sc->sc_ifp), ETHER_ADDR_LEN); =20 --=20 1.5.6.4 --- if_bridge-mac_inheritance.patch ends here --- > I wonder what the purpose of MAC inheritance is anyway... Multiple > unicast MACs in one segment sounds pretty odd. As was explained to me by Philip Paeps, ----- On 2008-08-15 18:24:29 (+0400), Eygene Ryabinkin wro= te: > I wonder what was the real need of the commit r180140, where you added > preemption of first bridge member MAC address by the bridge itself? There were two reasons: firstly, it makes the bridge more predictable across reboots, particularly in setups using DHCP. Secondly, this is the way the IEEE spec seems to suggest it should work. It is also the way other bridgi= ng implementations I've encountered work -- which suggests my reading of the s= pec is correct. ----- --=20 Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual =20 )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook=20 {_.-``-' {_/ # --UNifc18z8z6e1QHx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAki+ENcACgkQthUKNsbL7Yi/wgCgpyeZJSj2E5Bx7R8SdLN/gjRl DfMAnR76+UX8D/LtyeN8Upz2FNnufDZ9 =J9Nn -----END PGP SIGNATURE----- --UNifc18z8z6e1QHx-- From owner-freebsd-net@FreeBSD.ORG Wed Sep 3 08:00:05 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 297F3106567B for ; Wed, 3 Sep 2008 08:00:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id BC7188FC2C for ; Wed, 3 Sep 2008 08:00:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m83804OU058144 for ; Wed, 3 Sep 2008 08:00:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m838049V058143; Wed, 3 Sep 2008 08:00:04 GMT (envelope-from gnats) Date: Wed, 3 Sep 2008 08:00:04 GMT Message-Id: <200809030800.m838049V058143@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/126561: commit references a PR X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2008 08:00:05 -0000 The following reply was made to PR kern/126561; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/126561: commit references a PR Date: Wed, 3 Sep 2008 07:50:20 +0000 (UTC) dfr 2008-09-03 07:49:49 UTC FreeBSD src repository Modified files: (Branch: RELENG_7) sys/nlm nlm_prot_server.c Log: SVN rev 182712 on 2008-09-03 07:49:49Z by dfr MFC: r182153 - fix interoperability issues with Mac OS X. PR: 126561 Submitted by: Richard.Conto sy gmail.com Approved by: re (kensmith) Revision Changes Path 1.2.2.3 +1 -0 src/sys/nlm/nlm_prot_server.c _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Wed Sep 3 12:36:03 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C5651065670 for ; Wed, 3 Sep 2008 12:36:03 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by mx1.freebsd.org (Postfix) with ESMTP id 2D1AC8FC19 for ; Wed, 3 Sep 2008 12:36:02 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 88ED115BD25; Wed, 3 Sep 2008 08:36:02 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute2.internal (MEProxy); Wed, 03 Sep 2008 08:36:02 -0400 X-Sasl-enc: v0jBxUa66VuBF7oUpbk7rSVm/8PB0CTYCNk/5GlGL+2Y 1220445362 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id CCBB635F8D; Wed, 3 Sep 2008 08:36:01 -0400 (EDT) Message-ID: <48BE84B0.3080603@FreeBSD.org> Date: Wed, 03 Sep 2008 13:36:00 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.14 (X11/20080514) MIME-Version: 1.0 To: Joe Greco References: <200809021542.m82Fg9GK087484@aurora.sol.net> <48BD71DD.10707@FreeBSD.org> In-Reply-To: <48BD71DD.10707@FreeBSD.org> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, eugen@kuzbass.ru, jlin2918@yahoo.com Subject: Re: Quagga OSPF binds to wrong interface on FreeBSD 7 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, 03 Sep 2008 12:36:03 -0000 Bruce M. Simpson wrote: > > I understand that this situation has dragged on for some 18 months > since changes went into 7.x. I'm sorry to hear about the problems > you're having. I can't speak for Quagga as I haven't worked on it in > many years, nor can I speak for the Quagga patch. > I looked at the sockopt.c.diff patch briefly last night on my free time. It is a quick and dirty bandaid by the looks of it which just munges the socket options. It may "work for you", I haven't tested it as I don't run Quagga. BTW: The RFC 1724 hack was never actually documented, so code which relies on it is buggy and needs to be fixed. I published a patch for routed here nearly 18 months ago, which is probably where Quagga picked up the hack from. From owner-freebsd-net@FreeBSD.ORG Wed Sep 3 13:28:53 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F990106566C for ; Wed, 3 Sep 2008 13:28:53 +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 C21818FC15 for ; Wed, 3 Sep 2008 13:28:52 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m83DSkIO015670 for ; Wed, 3 Sep 2008 09:28:47 -0400 (EDT) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.8/8.13.3) with ESMTP id m83DSkfE058566 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 3 Sep 2008 09:28:46 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200809031328.m83DSkfE058566@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 03 Sep 2008 09:28:38 -0400 To: freebsd-net@freebsd.org From: Mike Tancsa In-Reply-To: <7.1.0.9.0.20080822120541.1122fba0@sentex.net> References: <7.1.0.9.0.20080822120541.1122fba0@sentex.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Subject: Re: strange TCP issue on RELENG_7 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, 03 Sep 2008 13:28:53 -0000 At 01:19 PM 8/22/2008, Mike Tancsa wrote: >On one of our sendmail boxes that we are running RELENG_7, we have >noticed an odd issue triggered or noticed by our monitoring system >(bigbrother in this case). The seems to have been happening ever >since we installed it, so its not a recent commit issue. Just following up, I am still seeing this issue on a recent stable from sept 2. (a sendmail box periodically sending an RST after successful 3way handshake) Monitoring host - 199.212.134.2, smtp host 199.212.134.9 From the sendmail host I see 08:19:32.780772 IP 199.212.134.2.64679 > 199.212.134.9.25: S 3568082086:3568082086(0) win 65535 08:19:32.780793 IP 199.212.134.9.25 > 199.212.134.2.64679: S 901330786:901330786(0) ack 3568082087 win 65535 08:19:32.781325 IP 199.212.134.2.64679 > 199.212.134.9.25: . ack 1 win 8326 08:19:32.781332 IP 199.212.134.9.25 > 199.212.134.2.64679: R 901330787:901330787(0) win 0 08:19:32.781334 IP 199.212.134.2.64679 > 199.212.134.9.25: P 1:7(6) ack 1 win 8326 08:19:32.781341 IP 199.212.134.9.25 > 199.212.134.2.64679: R 901330787:901330787(0) win 0 From the monitoring host 08:19:32.777919 IP 199.212.134.2.64679 > 199.212.134.9.25: S 3568082086:3568082086(0) win 65535 08:19:32.778448 IP 199.212.134.9.25 > 199.212.134.2.64679: S 901330786:901330786(0) ack 3568082087 win 65535 08:19:32.778470 IP 199.212.134.2.64679 > 199.212.134.9.25: . ack 1 win 8326 08:19:32.778479 IP 199.212.134.2.64679 > 199.212.134.9.25: P 1:7(6) ack 1 win 8326 08:19:32.778942 IP 199.212.134.9.25 > 199.212.134.2.64679: R 901330787:901330787(0) win 0 08:19:32.778951 IP 199.212.134.9.25 > 199.212.134.2.64679: R 901330787:901330787(0) win 0 There is no record of the connection in sendmail itself either and I have the LogLevel set to 11. On a normal connection from the monitoring host, I would see something like Sep 3 08:59:32 smtp2 sm-mta[14042]: NOQUEUE: connect from ns2.sentex.ca [199.212.134.2] Sep 3 08:59:32 smtp2 sm-mta[14042]: m83CxWHh014042: Milter (milter-ahead): init success to negotiate Sep 3 08:59:32 smtp2 sm-mta[14042]: m83CxWHh014042: Milter (clamav): init success to negotiate Sep 3 08:59:32 smtp2 sm-mta[14042]: m83CxWHh014042: Milter: connect to filters Sep 3 08:59:32 smtp2 sm-mta[14042]: m83CxWHh014042: ns2.sentex.ca [199.212.134.2] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA I tried running without pf (or any firewall) as well as disabling syncache but the problem would still happen (again, once or twice a day, sometimes once every 2 days). Does anyone have any other suggestions as to how to track down this issue ? I am a bit reluctant to move my other sendmail severs to RELENG_7 if the monitoring system is going to be tripping false positives like this. I am just running tcpdump on the main interface now to get a sense of how many times this is happening with connections in general and comparing it to the RELENG_6 boxes. ---Mike From owner-freebsd-net@FreeBSD.ORG Wed Sep 3 16:53:32 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 625FF1069F24 for ; Wed, 3 Sep 2008 16:53:32 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by mx1.freebsd.org (Postfix) with ESMTP id DDF8B8FC17 for ; Wed, 3 Sep 2008 16:53:31 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: by ey-out-2122.google.com with SMTP id 6so1177216eyi.7 for ; Wed, 03 Sep 2008 09:53:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:date:from:to:cc :subject:message-id:references:mime-version:content-type :content-disposition:in-reply-to:user-agent:sender; bh=8/T9ci/2+udDniYFtKLZuJLbOXH7/GcjG2RjwqYelHg=; b=gbVz8SDxPzEaQnhAwXsco9wArqB623xa5CKPcrvxaEdDVVSiHIJuFrutrBsEFT9VSF r0ORD8/2FODJ3YREnDFOC5iOC/rWFi38WNJ8sgO9TvsNHicKQJm9+qZHrbVUD4Xfa7Bt aQp6g+0sgZJxiZg6DC70iuswas7Wj+VS3q6yc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent:sender; b=p5/CFtVuXiX7R0woRLC8ucgmH8iXL9cjfIbD1G2f56trKXYPZMof/WCVU44ow+nqaO UpRnPzSNjlA/MKzpd8E5uT3BvmAhRA1wheocyv2HqYYrJYhvAklXTAxTf+SSQNyAiSgF c6h0UIqzYddZZia+SGayWgzhEdt30RoyRA1EY= Received: by 10.210.115.15 with SMTP id n15mr10373910ebc.81.1220460809245; Wed, 03 Sep 2008 09:53:29 -0700 (PDT) Received: from alpha.local ( [83.144.140.92]) by mx.google.com with ESMTPS id j8sm18896840gvb.1.2008.09.03.09.53.27 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 03 Sep 2008 09:53:28 -0700 (PDT) Received: by alpha.local (Postfix, from userid 1001) id 09009F4D9; Wed, 3 Sep 2008 17:52:31 +0100 (WEST) Date: Wed, 3 Sep 2008 17:52:31 +0100 From: Rui Paulo To: Vladimir Grebenschikov Message-ID: <20080903165230.GA31289@alpha.local> References: <200808280023.m7S0NN0B078088@repoman.freebsd.org> <1220382480.2493.5.camel@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1220382480.2493.5.camel@localhost> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: Rui Paulo Cc: freebsd-net@freebsd.org Subject: Re: cvs commit: src/sys/contrib/dev/ath COPYRIGHT README ah.h ah_desc.h ah_devid.h ah_soc.h version.h src/sys/contrib/dev/ath/public alpha-elf.hal.o.uu alpha-elf.inc alpha-elf.opt_ah.h ap30.hal.o.uu ap30.inc ap43.hal.o.uu ap43.inc ... 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, 03 Sep 2008 16:53:32 -0000 On Tue, Sep 02, 2008 at 11:08:00PM +0400, Vladimir Grebenschikov wrote: > ? Thu, 28/08/2008 ? 00:22 +0000, Rui Paulo ?????: > > rpaulo 2008-08-28 00:22:59 UTC > > > After that commit my wireless stop work: Can you tell us your ath mac+phy rev? -- Rui Paulo From owner-freebsd-net@FreeBSD.ORG Wed Sep 3 18:01:36 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C0E4107C1B9 for ; Wed, 3 Sep 2008 18:01:36 +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 546C98FC1B for ; Wed, 3 Sep 2008 18:01:36 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m83I1YYV076854 for ; Wed, 3 Sep 2008 14:01:34 -0400 (EDT) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.8/8.13.3) with ESMTP id m83I1Xwb059692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 3 Sep 2008 14:01:33 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200809031801.m83I1Xwb059692@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 03 Sep 2008 14:01:26 -0400 To: freebsd-net@freebsd.org From: Mike Tancsa In-Reply-To: <200809031328.m83DSkfE058566@lava.sentex.ca> References: <7.1.0.9.0.20080822120541.1122fba0@sentex.net> <200809031328.m83DSkfE058566@lava.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Subject: Re: strange TCP issue on RELENG_7 (probably solved) 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, 03 Sep 2008 18:01:36 -0000 At 09:28 AM 9/3/2008, Mike Tancsa wrote: >At 01:19 PM 8/22/2008, Mike Tancsa wrote: >>On one of our sendmail boxes that we are running RELENG_7, we have >>noticed an odd issue triggered or noticed by our monitoring system >>(bigbrother in this case). The seems to have been happening ever >>since we installed it, so its not a recent commit issue. > > >Just following up, I am still seeing this issue on a recent stable >from sept 2. (a sendmail box periodically sending an RST after >successful 3way handshake) OK, I think we might have found the issue. On the RELENG_7 box, the mc file didnt have define(`confCONNECTION_RATE_THROTTLE', `40')dnl which the other sendmail boxes have! Hopefully thats all it was and if so, sorry for the noise! ---Mike From owner-freebsd-net@FreeBSD.ORG Thu Sep 4 16:16:39 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2EDE106566C for ; Thu, 4 Sep 2008 16:16:39 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: from acm.poly.edu (acm.poly.edu [128.238.9.200]) by mx1.freebsd.org (Postfix) with ESMTP id 4CB1A8FC15 for ; Thu, 4 Sep 2008 16:16:38 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: (qmail 36008 invoked from network); 4 Sep 2008 15:49:57 -0000 Received: from unknown (HELO ?10.0.0.135?) (spawk@128.238.64.31) by acm.poly.edu with AES256-SHA encrypted SMTP; 4 Sep 2008 15:49:57 -0000 Message-ID: <48C00372.8030600@acm.poly.edu> Date: Thu, 04 Sep 2008 11:49:06 -0400 From: Boris Kochergin User-Agent: Thunderbird 2.0.0.16 (X11/20080727) MIME-Version: 1.0 To: Eugene Grosbein References: <47C428EC.3090909@acm.poly.edu> <20080226162307.GA80931@svzserv.kemerovo.su> <47C4439A.9050502@acm.poly.edu> <20080226175616.GC1509@heff.fud.org.nz> <47C4FB54.FF2F89EF@kuzbass.ru> In-Reply-To: <47C4FB54.FF2F89EF@kuzbass.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Andrew Thompson Subject: Re: if_gif/if_bridge 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: Thu, 04 Sep 2008 16:16:39 -0000 Eugene Grosbein wrote: >> Eugene, I take it the fix that applies on Boris's case is the >> M_BCAST|M_MCAST setting on the mbuf? I would like to test/commit this. >> > > I see you have already got it :-) > > >> Also, why to you add support for adding a bridge to a lagg interface? >> > > I needed to force lagg(4) to aggregate two EtherIP tunnels and now > I have it working :-) > > Eugene > _______________________________________________ > 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" > Ahoy. I've been using the patch for a while, and, recently, when the load on the wireless network I needed it for has increased, I've started getting kernel panics that I think the patch is responsible for. The panics are usually foreshadowed by messages in the style of "Sep 3 11:34:14 unique kernel: delayed m_pullup, m->len: 22 off: 38333 p: 97" in the kernel buffer. I like to think that I've eliminated the possibility of bad hardware by changing the motherboard, memory, and Ethernet controllers in the machine, and have tried both Eugene's original patchset and the one that was committed to 7-STABLE, with the same ill effects. Any ideas about what might be wrong, or shall I set about getting a backtrace? Thanks. -Boris From owner-freebsd-net@FreeBSD.ORG Thu Sep 4 16:49:57 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 902851065674 for ; Thu, 4 Sep 2008 16:49:57 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.freebsd.org (Postfix) with ESMTP id C05418FC18 for ; Thu, 4 Sep 2008 16:49:56 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from www.svzserv.kemerovo.su (eugen@localhost [127.0.0.1]) by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id m84Gnomm078794; Fri, 5 Sep 2008 00:49:50 +0800 (KRAST) (envelope-from eugen@www.svzserv.kemerovo.su) Received: (from eugen@localhost) by www.svzserv.kemerovo.su (8.13.8/8.13.8/Submit) id m84GnnP7078793; Fri, 5 Sep 2008 00:49:49 +0800 (KRAST) (envelope-from eugen) Date: Fri, 5 Sep 2008 00:49:49 +0800 From: Eugene Grosbein To: Boris Kochergin Message-ID: <20080904164949.GA76939@svzserv.kemerovo.su> References: <47C428EC.3090909@acm.poly.edu> <20080226162307.GA80931@svzserv.kemerovo.su> <47C4439A.9050502@acm.poly.edu> <20080226175616.GC1509@heff.fud.org.nz> <47C4FB54.FF2F89EF@kuzbass.ru> <48C00372.8030600@acm.poly.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48C00372.8030600@acm.poly.edu> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org, Andrew Thompson Subject: Re: if_gif/if_bridge 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: Thu, 04 Sep 2008 16:49:57 -0000 On Thu, Sep 04, 2008 at 11:49:06AM -0400, Boris Kochergin wrote: > Ahoy. I've been using the patch for a while, and, recently, when the > load on the wireless network I needed it for has increased, I've started > getting kernel panics that I think the patch is responsible for. The > panics are usually foreshadowed by messages in the style of "Sep 3 > 11:34:14 unique kernel: delayed m_pullup, m->len: 22 off: 38333 p: 97" > in the kernel buffer. I like to think that I've eliminated the > possibility of bad hardware by changing the motherboard, memory, and > Ethernet controllers in the machine, and have tried both Eugene's > original patchset and the one that was committed to 7-STABLE, with the > same ill effects. Any ideas about what might be wrong, or shall I set > about getting a backtrace? Thanks. Yes, you should. And I think you no more need my patches after Andrew's fixes to gif(4). But if you need my changes to lagg(4), you should now use version corrected to apply to recent RELENG_7: ftp://www.kuzbass.ru/pub/freebsd/lagg-0.2.tgz There were no functional changes, only context changes after Anrew's commit. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Thu Sep 4 17:00:27 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6224D10656B0 for ; Thu, 4 Sep 2008 17:00:27 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from pele.citylink.co.nz (pele.citylink.co.nz [202.8.44.226]) by mx1.freebsd.org (Postfix) with ESMTP id DA8E68FC23 for ; Thu, 4 Sep 2008 17:00:26 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by pele.citylink.co.nz (Postfix) with ESMTP id 48EC62BD29; Fri, 5 Sep 2008 05:00:25 +1200 (NZST) X-Virus-Scanned: Debian amavisd-new at citylink.co.nz Received: from pele.citylink.co.nz ([127.0.0.1]) by localhost (pele.citylink.co.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aMnCn0YS7+LP; Fri, 5 Sep 2008 05:00:18 +1200 (NZST) Received: from citylink.fud.org.nz (unknown [202.8.44.45]) by pele.citylink.co.nz (Postfix) with ESMTP; Fri, 5 Sep 2008 05:00:18 +1200 (NZST) Received: by citylink.fud.org.nz (Postfix, from userid 1001) id BF9831142E; Fri, 5 Sep 2008 05:00:17 +1200 (NZST) Date: Thu, 4 Sep 2008 10:00:17 -0700 From: Andrew Thompson To: Eugene Grosbein Message-ID: <20080904170017.GE23667@citylink.fud.org.nz> References: <47C428EC.3090909@acm.poly.edu> <20080226162307.GA80931@svzserv.kemerovo.su> <47C4439A.9050502@acm.poly.edu> <20080226175616.GC1509@heff.fud.org.nz> <47C4FB54.FF2F89EF@kuzbass.ru> <48C00372.8030600@acm.poly.edu> <20080904164949.GA76939@svzserv.kemerovo.su> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080904164949.GA76939@svzserv.kemerovo.su> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-net@freebsd.org, Boris Kochergin Subject: Re: if_gif/if_bridge 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: Thu, 04 Sep 2008 17:00:27 -0000 On Fri, Sep 05, 2008 at 12:49:49AM +0800, Eugene Grosbein wrote: > On Thu, Sep 04, 2008 at 11:49:06AM -0400, Boris Kochergin wrote: > > > Ahoy. I've been using the patch for a while, and, recently, when the > > load on the wireless network I needed it for has increased, I've started > > getting kernel panics that I think the patch is responsible for. The > > panics are usually foreshadowed by messages in the style of "Sep 3 > > 11:34:14 unique kernel: delayed m_pullup, m->len: 22 off: 38333 p: 97" > > in the kernel buffer. I like to think that I've eliminated the > > possibility of bad hardware by changing the motherboard, memory, and > > Ethernet controllers in the machine, and have tried both Eugene's > > original patchset and the one that was committed to 7-STABLE, with the > > same ill effects. Any ideas about what might be wrong, or shall I set > > about getting a backtrace? Thanks. > > Yes, you should. And I think you no more need my patches after > Andrew's fixes to gif(4). But if you need my changes to lagg(4), > you should now use version corrected to apply to recent RELENG_7: > ftp://www.kuzbass.ru/pub/freebsd/lagg-0.2.tgz > > There were no functional changes, only context changes after Anrew's commit. Im not too sure about adding media attachments to the bridge. I have long forgotten the network layout you are trying to achieve, can you describe it again. It may be better to allow media-less interfaces to be added to lagg(4). Andrew From owner-freebsd-net@FreeBSD.ORG Fri Sep 5 02:24:29 2008 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3207A1065678; Fri, 5 Sep 2008 02:24:29 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.freebsd.org (Postfix) with ESMTP id 857DF8FC12; Fri, 5 Sep 2008 02:24:28 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from www.svzserv.kemerovo.su (eugen@localhost [127.0.0.1]) by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id m852ONuY089915; Fri, 5 Sep 2008 10:24:23 +0800 (KRAST) (envelope-from eugen@www.svzserv.kemerovo.su) Received: (from eugen@localhost) by www.svzserv.kemerovo.su (8.13.8/8.13.8/Submit) id m852OMKa089914; Fri, 5 Sep 2008 10:24:22 +0800 (KRAST) (envelope-from eugen) Date: Fri, 5 Sep 2008 10:24:22 +0800 From: Eugene Grosbein To: Andrew Thompson Message-ID: <20080905022422.GA89543@svzserv.kemerovo.su> References: <47C428EC.3090909@acm.poly.edu> <20080226162307.GA80931@svzserv.kemerovo.su> <47C4439A.9050502@acm.poly.edu> <20080226175616.GC1509@heff.fud.org.nz> <47C4FB54.FF2F89EF@kuzbass.ru> <48C00372.8030600@acm.poly.edu> <20080904164949.GA76939@svzserv.kemerovo.su> <20080904170017.GE23667@citylink.fud.org.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080904170017.GE23667@citylink.fud.org.nz> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@FreeBSD.org, Boris Kochergin Subject: Re: if_gif/if_bridge 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, 05 Sep 2008 02:24:29 -0000 On Thu, Sep 04, 2008 at 10:00:17AM -0700, Andrew Thompson wrote: > Im not too sure about adding media attachments to the bridge. I have > long forgotten the network layout you are trying to achieve, can you > describe it again. Just to aggregate two bridges with lagg(4) > It may be better to allow media-less interfaces to be added to lagg(4). May be. I just desided to gather all changes in bridge code :-) Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Fri Sep 5 03:16:48 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 966B91065675; Fri, 5 Sep 2008 03:16:48 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 6F5BD8FC12; Fri, 5 Sep 2008 03:16:48 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m853GmhZ087291; Fri, 5 Sep 2008 03:16:48 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m853GmOf087287; Fri, 5 Sep 2008 03:16:48 GMT (envelope-from linimon) Date: Fri, 5 Sep 2008 03:16:48 GMT Message-Id: <200809050316.m853GmOf087287@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-amd64@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/127102: [wpi] Intel 3945ABG low throughput 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, 05 Sep 2008 03:16:48 -0000 Old Synopsis: Intel 3945ABG (wpi) low throughput New Synopsis: [wpi] Intel 3945ABG low throughput Responsible-Changed-From-To: freebsd-amd64->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Sep 5 03:16:19 UTC 2008 Responsible-Changed-Why: Probably not amd64-specific. http://www.freebsd.org/cgi/query-pr.cgi?pr=127102 From owner-freebsd-net@FreeBSD.ORG Fri Sep 5 04:20:04 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1BBE106564A for ; Fri, 5 Sep 2008 04:20:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E2FDA8FC08 for ; Fri, 5 Sep 2008 04:20:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m854K4cJ092559 for ; Fri, 5 Sep 2008 04:20:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m854K40g092558; Fri, 5 Sep 2008 04:20:04 GMT (envelope-from gnats) Date: Fri, 5 Sep 2008 04:20:04 GMT Message-Id: <200809050420.m854K40g092558@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: "j0 m4m4" Cc: Subject: Re: kern/127102: [wpi] Intel 3945ABG low throughput X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j0 m4m4 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2008 04:20:05 -0000 The following reply was made to PR kern/127102; it has been noted by GNATS. From: "j0 m4m4" To: bug-followup@FreeBSD.org, figyshki@gmail.com Cc: Subject: Re: kern/127102: [wpi] Intel 3945ABG low throughput Date: Thu, 4 Sep 2008 23:43:33 -0400 ------=_Part_14797_25734829.1220586213145 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Same hardware has no issues under Windows and OpenSuSe 10.3 (x86_64). ------=_Part_14797_25734829.1220586213145 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Same hardware has no issues under Windows and OpenSuSe 10.3 (x86_64).
------=_Part_14797_25734829.1220586213145-- From owner-freebsd-net@FreeBSD.ORG Fri Sep 5 07:56:15 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E558106566B for ; Fri, 5 Sep 2008 07:56:15 +0000 (UTC) (envelope-from freebsd-net@dino.sk) Received: from loki.netlab.sk (loki.netlab.sk [84.245.65.11]) by mx1.freebsd.org (Postfix) with ESMTP id 3B4BA8FC17 for ; Fri, 5 Sep 2008 07:56:14 +0000 (UTC) (envelope-from freebsd-net@dino.sk) Received: from via.dino.sk (home.dino.sk [84.245.95.252]) (AUTH: PLAIN milan, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by loki.netlab.sk with esmtp; Fri, 05 Sep 2008 09:44:46 +0200 id 0002E010.48C0E36E.0000EB4F From: Milan Obuch To: freebsd-net@freebsd.org Date: Fri, 5 Sep 2008 09:45:08 +0200 User-Agent: KMail/1.9.10 X-KMail-CryptoMessageFormat: 15 MIME-Version: 1.0 Content-Disposition: inline X-Length: 2483 X-UID: 262 Message-Id: <200809050945.09276.freebsd-net@dino.sk> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: MSI Wind Notebook's network interfaces 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, 05 Sep 2008 07:56:15 -0000 Hi, I have new notebook, MSI's Wind, and installed succesfully both FreeBSD-7 and -CURRENT. In 7.0-RELEASE wired network interface did not work, but after upgrading to 7-STABLE (now 7.1-PRERELEASE) it work with re driver. There is just one small uglyness - it's link level address (MAC) is 00:00:00:00:00:00. Needless to say, Windows initializes this to 00:1d:92:59:f5:8b. I can change it with 'ifconfig re0 ether 00:1d:92:59:f5:8b', but I would rather let the driver to find the correct MAC. While everything works (I am csup'ing sources over its re0, which is a good test in my experience), if anybody have any idea/patch to test, I would like to do it. Some data collected: ifconfig re0 re0: flags=8843 metric 0 mtu 1500 options=389b ether 00:00:00:00:00:00 inet 192.168.16.235 netmask 0xffffff00 broadcast 192.168.16.255 media: Ethernet autoselect (100baseTX ) status: active pciconf -lcv (part of) re0@pci0:1:0:0: class=0x020000 card=0x01101462 chip=0x813610ec rev=0x02 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RTL8139/810x Family Fast Ethernet NIC' class = network subclass = ethernet cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 cap 05[50] = MSI supports 1 message, 64 bit cap 10[70] = PCI-Express 2 endpoint IRQ 0 cap 11[ac] = MSI-X supports 2 messages in map 0x20 cap 03[cc] = VPD dmesg (part of verbose boot) re0: port 0xc000-0xc0ff mem 0xffd10000-0xffd10fff,0xffd00000-0xffd0ffff irq 16 at device 0.0 on pci1 re0: Reserved 0x1000 bytes for rid 0x18 type 3 at 0xffd10000 re0: MSI count : 1 re0: Chip rev. 0x34800000 re0: MAC rev. 0x00200000 miibus0: on re0 rlphy0: PHY 1 on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto re0: bpf attached re0: [MPSAFE] re0: [FILTER] When not booting verbose, there is also one line telling re0: turning off MSI enable bit. This netbook has also wireless interface, but this one does not get detected (or I have no driver for it), in dmesg there is only line telling pci2: at device 0.0 (no driver attached) and relevant part of pciconf -lcv is none0@pci0:2:0:0: class=0x028000 card=0x68941462 chip=0x819910ec rev=0x22 hdr=0x00 vendor = 'Realtek Semiconductor' class = network cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 cap 05[50] = MSI supports 1 message, 64 bit cap 10[70] = PCI-Express 1 legacy endpoint While currently I have no urge need for wireless connectivity, in the long run I would like to use it. Currently I can't change card (probably minipci) as netbook is under warranty, with 'warranty sticker - void if tampered' over screw. If anybody had some idea how to fix MAC address initialization for wired interface or what driver to use for wireless interface (I will probably try NDIS, but my experience in this area is limited and previous succesfull try none), I am all ears. Regars, Milan From owner-freebsd-net@FreeBSD.ORG Fri Sep 5 08:23:32 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A9391065674 for ; Fri, 5 Sep 2008 08:23:32 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.229]) by mx1.freebsd.org (Postfix) with ESMTP id 016FE8FC13 for ; Fri, 5 Sep 2008 08:23:31 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so453007rvf.43 for ; Fri, 05 Sep 2008 01:23:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from :to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=2v01+UEB4X8tcdgIfWuInNnRpGJYq5GZ7rUSHke6RyU=; b=YK1Yx8+cvzZ8nSGyq4dKwHhm72JVq9iCVsVfcXQ7zu2vjlAFRg7jwFoRGVaPILc/6o TSPYMushUnyQQMXydhALpe6aOHYiMtyfDcTYHOPq/xXYbK4zYwmPqOjj9DKEJLA02MGE I2BCIRO7hV9eevsUSHH8USBQqcF6RdrbgrCOc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=qNJqHoAdi3bAo0lKt9tvCelubJVSSD2fAoPnrx789wfLWKpQUPAB07SBcqwxo4dwS8 Hi0P0i+mbEeVuVxfTbTZgxcfa8jhyX0zZr+ncaTVuLcRndMOfWHZYG2mUZEDfthvvL9g BRBj+OnO1C3YAYGrdHUFCc4Ctc+gbyB+iq8j4= Received: by 10.140.135.19 with SMTP id i19mr5276664rvd.169.1220603011654; Fri, 05 Sep 2008 01:23:31 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id b8sm19179902rvf.4.2008.09.05.01.23.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 05 Sep 2008 01:23:30 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id m858NQoW067172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Sep 2008 17:23:26 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id m858NMmT067171; Fri, 5 Sep 2008 17:23:22 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Fri, 5 Sep 2008 17:23:22 +0900 From: Pyun YongHyeon To: Milan Obuch Message-ID: <20080905082322.GA66951@cdnetworks.co.kr> References: <200809050945.09276.freebsd-net@dino.sk> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="gBBFr7Ir9EOA20Yy" Content-Disposition: inline In-Reply-To: <200809050945.09276.freebsd-net@dino.sk> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org Subject: Re: MSI Wind Notebook's network interfaces X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2008 08:23:32 -0000 --gBBFr7Ir9EOA20Yy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Sep 05, 2008 at 09:45:08AM +0200, Milan Obuch wrote: > Hi, > I have new notebook, MSI's Wind, and installed succesfully both FreeBSD-7 > and -CURRENT. > > In 7.0-RELEASE wired network interface did not work, but after upgrading to > 7-STABLE (now 7.1-PRERELEASE) it work with re driver. There is just one small > uglyness - it's link level address (MAC) is 00:00:00:00:00:00. Needless to > say, Windows initializes this to 00:1d:92:59:f5:8b. I can change it > with 'ifconfig re0 ether 00:1d:92:59:f5:8b', but I would rather let the > driver to find the correct MAC. > > While everything works (I am csup'ing sources over its re0, which is a good > test in my experience), if anybody have any idea/patch to test, I would like > to do it. > > Some data collected: > > ifconfig re0 > re0: flags=8843 metric 0 mtu 1500 > > options=389b > ether 00:00:00:00:00:00 > inet 192.168.16.235 netmask 0xffffff00 broadcast 192.168.16.255 > media: Ethernet autoselect (100baseTX ) > status: active > > pciconf -lcv (part of) > re0@pci0:1:0:0: class=0x020000 card=0x01101462 chip=0x813610ec rev=0x02 > hdr=0x00 > vendor = 'Realtek Semiconductor' > device = 'RTL8139/810x Family Fast Ethernet NIC' > class = network > subclass = ethernet > cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 > cap 05[50] = MSI supports 1 message, 64 bit > cap 10[70] = PCI-Express 2 endpoint IRQ 0 > cap 11[ac] = MSI-X supports 2 messages in map 0x20 > cap 03[cc] = VPD > > dmesg (part of verbose boot) > re0: port 0xc000-0xc0ff mem > 0xffd10000-0xffd10fff,0xffd00000-0xffd0ffff irq 16 at device 0.0 on pci1 > re0: Reserved 0x1000 bytes for rid 0x18 type 3 at 0xffd10000 > re0: MSI count : 1 > re0: Chip rev. 0x34800000 > re0: MAC rev. 0x00200000 > miibus0: on re0 > rlphy0: PHY 1 on miibus0 > rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > re0: bpf attached > re0: [MPSAFE] > re0: [FILTER] > > When not booting verbose, there is also one line telling > re0: turning off MSI enable bit. > re(4) cleared MSI enable bit of configuration register as MSI wouldn't be used. You can ignore this. > This netbook has also wireless interface, but this one does not get detected > (or I have no driver for it), in dmesg there is only line telling > pci2: at device 0.0 (no driver attached) > > and relevant part of pciconf -lcv is > none0@pci0:2:0:0: class=0x028000 card=0x68941462 chip=0x819910ec > rev=0x22 hdr=0x00 > vendor = 'Realtek Semiconductor' > class = network > cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 > cap 05[50] = MSI supports 1 message, 64 bit > cap 10[70] = PCI-Express 1 legacy endpoint > > While currently I have no urge need for wireless connectivity, in the long run > I would like to use it. Currently I can't change card (probably minipci) as > netbook is under warranty, with 'warranty sticker - void if tampered' over > screw. > > If anybody had some idea how to fix MAC address initialization for wired Would you try attached patch? > interface or what driver to use for wireless interface (I will probably try > NDIS, but my experience in this area is limited and previous succesfull try > none), I am all ears. > > Regars, > Milan -- Regards, Pyun YongHyeon --gBBFr7Ir9EOA20Yy Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="re.810E.patch" --- sys/dev/re/if_re.c.orig Wed Aug 13 12:40:08 2008 +++ sys/dev/re/if_re.c Fri Sep 5 17:18:40 2008 @@ -1213,7 +1213,8 @@ case RL_HWREV_8102E: case RL_HWREV_8102EL: sc->rl_flags |= RL_FLAG_NOJUMBO | RL_FLAG_INVMAR | - RL_FLAG_PHYWAKE | RL_FLAG_DESCV2 | RL_FLAG_MACSTAT; + RL_FLAG_PHYWAKE | RL_FLAG_PAR | RL_FLAG_DESCV2 | + RL_FLAG_MACSTAT; break; case RL_HWREV_8168_SPIN1: case RL_HWREV_8168_SPIN2: --gBBFr7Ir9EOA20Yy-- From owner-freebsd-net@FreeBSD.ORG Fri Sep 5 14:44:54 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 303BD1065675 for ; Fri, 5 Sep 2008 14:44:54 +0000 (UTC) (envelope-from freebsd-net@dino.sk) Received: from loki.netlab.sk (loki.netlab.sk [84.245.65.11]) by mx1.freebsd.org (Postfix) with ESMTP id B868D8FC18 for ; Fri, 5 Sep 2008 14:44:53 +0000 (UTC) (envelope-from freebsd-net@dino.sk) Received: from via.dino.sk (home.dino.sk [84.245.95.252]) (AUTH: PLAIN milan, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by loki.netlab.sk with esmtp; Fri, 05 Sep 2008 16:43:24 +0200 id 0002E010.48C1458C.0000F8C7 From: Milan Obuch To: pyunyh@gmail.com, freebsd-net@freebsd.org Date: Fri, 5 Sep 2008 16:43:51 +0200 User-Agent: KMail/1.9.7 References: <200809050945.09276.freebsd-net@dino.sk> <20080905082322.GA66951@cdnetworks.co.kr> In-Reply-To: <20080905082322.GA66951@cdnetworks.co.kr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200809051643.52950.freebsd-net@dino.sk> Cc: Subject: Re: MSI Wind Notebook's network interfaces 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, 05 Sep 2008 14:44:54 -0000 On Friday 05 September 2008 10:23:22 Pyun YongHyeon wrote: > On Fri, Sep 05, 2008 at 09:45:08AM +0200, Milan Obuch wrote: [ snip ] > > In 7.0-RELEASE wired network interface did not work, but after upgrading > > to 7-STABLE (now 7.1-PRERELEASE) it work with re driver. There is just > > one small uglyness - it's link level address (MAC) is 00:00:00:00:00:00. > > Needless to say, Windows initializes this to 00:1d:92:59:f5:8b. I can > > change it with 'ifconfig re0 ether 00:1d:92:59:f5:8b', but I would > > rather let the driver to find the correct MAC. [ snip ] > > dmesg (part of verbose boot) > > re0: port 0xc000-0xc0ff > > mem 0xffd10000-0xffd10fff,0xffd00000-0xffd0ffff irq 16 at device 0.0 on > > pci1 re0: Reserved 0x1000 bytes for rid 0x18 type 3 at 0xffd10000 > > re0: MSI count : 1 > > re0: Chip rev. 0x34800000 > > re0: MAC rev. 0x00200000 > > miibus0: on re0 > > rlphy0: PHY 1 on miibus0 > > rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > > re0: bpf attached > > re0: [MPSAFE] > > re0: [FILTER] > > > > When not booting verbose, there is also one line telling > > re0: turning off MSI enable bit. > > re(4) cleared MSI enable bit of configuration register as MSI > wouldn't be used. You can ignore this. > OK, but what surprised me a bit was the fact this line is not present in dmesg when booting verbose. I would expect all lines from normal boot in verbose boot... > > This netbook has also wireless interface, but this one does not get > > detected (or I have no driver for it), in dmesg there is only line > > telling pci2: at device 0.0 (no driver attached) > > > > and relevant part of pciconf -lcv is > > none0@pci0:2:0:0: class=0x028000 card=0x68941462 chip=0x819910ec > > rev=0x22 hdr=0x00 > > vendor = 'Realtek Semiconductor' > > class = network > > cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 > > cap 05[50] = MSI supports 1 message, 64 bit > > cap 10[70] = PCI-Express 1 legacy endpoint > > > > While currently I have no urge need for wireless connectivity, in the > > long run I would like to use it. Currently I can't change card (probably > > minipci) as netbook is under warranty, with 'warranty sticker - void if > > tampered' over screw. > > > > If anybody had some idea how to fix MAC address initialization for wired > > Would you try attached patch? > I tried on freshly csup'ped head and it works. Ethernet link address is now correctly set. Great! It looks like a kind of magic at first glance :) > > interface or what driver to use for wireless interface (I will probably > > try NDIS, but my experience in this area is limited and previous > > succesfull try none), I am all ears. Could anybody comment on wireless interface? Regards, Milan From owner-freebsd-net@FreeBSD.ORG Fri Sep 5 16:40:59 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5559D1065670 for ; Fri, 5 Sep 2008 16:40:59 +0000 (UTC) (envelope-from redchin@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.186]) by mx1.freebsd.org (Postfix) with ESMTP id D952E8FC12 for ; Fri, 5 Sep 2008 16:40:58 +0000 (UTC) (envelope-from redchin@gmail.com) Received: by nf-out-0910.google.com with SMTP id h3so150295nfh.33 for ; Fri, 05 Sep 2008 09:40:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=v1I15JnnhNR/aiOvBaqY7L7NEZFJttuE+khtiaBChSE=; b=gXPW47TXJAXpDxvEyqaOaQfwgAeTT7POSkIbupxfngwP16YU7PbrH3qX7TQg9ZQNPI 013jZF4ui7P/VUlmsxyFCPDpgEsh8/z03R9TQpM8o961yKMBVwO/k0Yv8PXpE4iiqBNP hF90x0Y9wh7s3Z8vmIL+cSjBDmqQ1Nf95jIQ8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=KUhBo5oJwrHP2WBfaP0h12/Blie3W/78ynOpLuq9V2S8zGB/kWhYNLUSUr5PjBrASf 2x5Ero5xiiSJ1J1QKtAhsPv+nXKnuN81ym7bA9UPLd8xhX3KnbBMOdT4v8t9YF5qtFWk HeYXthxT58yjHZ5W8fa6qiJdS5JbGep4ENwvo= Received: by 10.210.131.6 with SMTP id e6mr13971159ebd.10.1220631225430; Fri, 05 Sep 2008 09:13:45 -0700 (PDT) Received: by 10.210.66.19 with HTTP; Fri, 5 Sep 2008 09:13:45 -0700 (PDT) Message-ID: <1d3ed48c0809050913h7a9b69eas14476c9e9c7071d5@mail.gmail.com> Date: Fri, 5 Sep 2008 09:13:45 -0700 From: "Kevin Downey" To: "Milan Obuch" In-Reply-To: <200809051643.52950.freebsd-net@dino.sk> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200809050945.09276.freebsd-net@dino.sk> <20080905082322.GA66951@cdnetworks.co.kr> <200809051643.52950.freebsd-net@dino.sk> Cc: pyunyh@gmail.com, freebsd-net@freebsd.org Subject: Re: MSI Wind Notebook's network interfaces 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, 05 Sep 2008 16:40:59 -0000 On Fri, Sep 5, 2008 at 7:43 AM, Milan Obuch wrote: > [ snip ] > Could anybody comment on wireless interface? I could not get the internal wifi to work with ndis wrapper. It appears that using the rtw driver netbsd, openbsd, and dragonflybsd all support this chipset. I found a (polish?) webpage with a very preliminary attempt at porting the rtw driver. The author of the port said it doesn't really work. I just gave up and bought a usb wifi stick. -- The Mafia way is that we pursue larger goals under the guise of personal relationships. Fisheye From owner-freebsd-net@FreeBSD.ORG Fri Sep 5 19:46:37 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B788F1065674 for ; Fri, 5 Sep 2008 19:46:37 +0000 (UTC) (envelope-from milan@dino.sk) Received: from loki.netlab.sk (loki.netlab.sk [84.245.65.11]) by mx1.freebsd.org (Postfix) with ESMTP id 111D98FC13 for ; Fri, 5 Sep 2008 19:46:36 +0000 (UTC) (envelope-from milan@dino.sk) Received: from via.dino.sk (home.dino.sk [84.245.95.252]) (AUTH: PLAIN milan, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by loki.netlab.sk with esmtp; Fri, 05 Sep 2008 21:35:00 +0200 id 0002E010.48C189E4.0001047F From: Milan Obuch To: freebsd-net@freebsd.org, pyunyh@gmail.com Date: Fri, 5 Sep 2008 21:35:26 +0200 User-Agent: KMail/1.9.7 References: <200809050945.09276.freebsd-net@dino.sk> <20080905082322.GA66951@cdnetworks.co.kr> <200809051643.52950.freebsd-net@dino.sk> In-Reply-To: <200809051643.52950.freebsd-net@dino.sk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200809052135.27899.milan@dino.sk> Cc: Subject: Re: MSI Wind Notebook's network interfaces 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, 05 Sep 2008 19:46:37 -0000 On Friday 05 September 2008 16:43:51 Milan Obuch wrote: > On Friday 05 September 2008 10:23:22 Pyun YongHyeon wrote: > > On Fri, Sep 05, 2008 at 09:45:08AM +0200, Milan Obuch wrote: > > [ snip ] > > > > In 7.0-RELEASE wired network interface did not work, but after > > > upgrading to 7-STABLE (now 7.1-PRERELEASE) it work with re driver. > > > There is just one small uglyness - it's link level address (MAC) is > > > 00:00:00:00:00:00. Needless to say, Windows initializes this to > > > 00:1d:92:59:f5:8b. I can change it with 'ifconfig re0 ether > > > 00:1d:92:59:f5:8b', but I would rather let the driver to find the > > > correct MAC. [ snip ] > > > If anybody had some idea how to fix MAC address initialization for > > > wired > > > > Would you try attached patch? > > I tried on freshly csup'ped head and it works. Ethernet link address is now > correctly set. Great! It looks like a kind of magic at first glance :) > > > > interface or what driver to use for wireless interface (I will > > > probably try NDIS, but my experience in this area is limited and > > > previous succesfull try none), I am all ears. > > Could anybody comment on wireless interface? > I csup'ped 7.1-PRERELEASE, apply this patch and it work just like in HEAD. Just FYI. Regards, Milan From owner-freebsd-net@FreeBSD.ORG Fri Sep 5 20:24:02 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C4AB8106567D for ; Fri, 5 Sep 2008 20:24:02 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outH.internet-mail-service.net (outh.internet-mail-service.net [216.240.47.231]) by mx1.freebsd.org (Postfix) with ESMTP id A73EF8FC1B for ; Fri, 5 Sep 2008 20:24:02 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 225E22488 for ; Fri, 5 Sep 2008 13:24:03 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 0682A2D601E for ; Fri, 5 Sep 2008 13:24:01 -0700 (PDT) Message-ID: <48C19568.807@elischer.org> Date: Fri, 05 Sep 2008 13:24:08 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: FreeBSD Net Content-Type: multipart/mixed; boundary="------------040202050603070306030307" Subject: rewrite of rt_check() (now rt_check_fib()) 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, 05 Sep 2008 20:24:02 -0000 This is a multi-part message in MIME format. --------------040202050603070306030307 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit In tryin gto understand rt_check_fib() (wsa rt_check()) I ended up rewriting it to do what I thought it was trying to do.. this stops the panics some people have seen, but allows the system to stay up long enough to see some other problem.. anyhow this si the patch: comments? --------------040202050603070306030307 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="adiff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="adiff" Index: route.c =================================================================== RCS file: /home/ncvs/src/sys/net/route.c,v retrieving revision 1.134 diff -u -r1.134 route.c --- route.c 1 Sep 2008 17:15:29 -0000 1.134 +++ route.c 5 Sep 2008 20:23:32 -0000 @@ -1676,16 +1676,18 @@ * *lrt0 points to the cached route to the final destination; * *lrt is not meaningful; * fibnum is the index to the correct network fib for this packet + * (*lrt0 has not ref held on it so REMREF is not needed ) * * === Operation === * If the route is marked down try to find a new route. If the route * to the gateway is gone, try to setup a new route. Otherwise, * if the route is marked for packets to be rejected, enforce that. + * Note that rtalloc returns an rtentry with an extra REF that we need to lose. * * === On return === * *dst is unchanged; * *lrt0 points to the (possibly new) route to the final destination - * *lrt points to the route to the next hop + * *lrt points to the route to the next hop [LOCKED] * * Their values are meaningful ONLY if no error is returned. */ @@ -1704,49 +1706,56 @@ int error; KASSERT(*lrt0 != NULL, ("rt_check")); - rt = rt0 = *lrt0; + rt0 = *lrt0; + rt = NULL; /* NB: the locking here is tortuous... */ - RT_LOCK(rt); - if ((rt->rt_flags & RTF_UP) == 0) { - RT_UNLOCK(rt); - rt = rtalloc1_fib(dst, 1, 0UL, fibnum); - if (rt != NULL) { - RT_REMREF(rt); + RT_LOCK(rt0); + if ((rt0->rt_flags & RTF_UP) == 0) { + /* Current rt0 is useless, try get a replacement. */ + RT_UNLOCK(rt0); + rt0 = rtalloc1_fib(dst, 1, 0UL, fibnum); + if ((rt0 != NULL)/* && (rt0->rt_flags & RTF_UP) */) { + RT_REMREF(rt0); /* XXX what about if change? */ - } else + } else { return (EHOSTUNREACH); - rt0 = rt; + } } + /* XXX BSD/OS checks dst->sa_family != AF_NS */ - if (rt->rt_flags & RTF_GATEWAY) { - if (rt->rt_gwroute == NULL) - goto lookup; - rt = rt->rt_gwroute; - RT_LOCK(rt); /* NB: gwroute */ - if ((rt->rt_flags & RTF_UP) == 0) { - RTFREE_LOCKED(rt); /* unlock gwroute */ - rt = rt0; - rt0->rt_gwroute = NULL; - lookup: + if (rt0->rt_flags & RTF_GATEWAY) { + if ((rt = rt0->rt_gwroute) != NULL) { + RT_LOCK(rt); /* NB: gwroute */ + if ((rt->rt_flags & RTF_UP) == 0) { + /* gw route is dud. ignore/lose it */ + RTFREE_LOCKED(rt); /* unlock gwroute */ + rt = rt0->rt_gwroute = NULL; + } + } + + + if (rt == NULL) { /* NOT AN ELSE CLAUSE */ RT_UNLOCK(rt0); -/* XXX MRT link level looked up in table 0 */ - rt = rtalloc1_fib(rt->rt_gateway, 1, 0UL, 0); + /* XXX MRT link level looked up in table 0 */ + rt = rtalloc1_fib(rt0->rt_gateway, 1, 0UL, fibnum); if (rt == rt0) { - RT_REMREF(rt0); - RT_UNLOCK(rt0); + /* the best we can do is not good enough */ + /* XXX does this happen? */ + RT_REMREF(rt); + RT_UNLOCK(rt); return (ENETUNREACH); } RT_LOCK(rt0); - if (rt0->rt_gwroute != NULL) - RTFREE(rt0->rt_gwroute); - rt0->rt_gwroute = rt; if (rt == NULL) { RT_UNLOCK(rt0); return (EHOSTUNREACH); } + rt0->rt_gwroute = rt; } RT_UNLOCK(rt0); + } else { + rt = rt0; } /* XXX why are we inspecting rmx_expire? */ error = (rt->rt_flags & RTF_REJECT) && --------------040202050603070306030307-- From owner-freebsd-net@FreeBSD.ORG Fri Sep 5 22:49:18 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8AF71065685 for ; Fri, 5 Sep 2008 22:49:18 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outM.internet-mail-service.net (outm.internet-mail-service.net [216.240.47.236]) by mx1.freebsd.org (Postfix) with ESMTP id A73C38FC17 for ; Fri, 5 Sep 2008 22:49:18 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id C94FE2488 for ; Fri, 5 Sep 2008 15:49:18 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id C06762D601A for ; Fri, 5 Sep 2008 15:49:17 -0700 (PDT) Message-ID: <48C1B774.2020405@elischer.org> Date: Fri, 05 Sep 2008 15:49:24 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: FreeBSD Net References: <48C19568.807@elischer.org> In-Reply-To: <48C19568.807@elischer.org> Content-Type: multipart/mixed; boundary="------------010409070303080805060805" Subject: Re: rewrite of rt_check() (now rt_check_fib()) 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, 05 Sep 2008 22:49:18 -0000 This is a multi-part message in MIME format. --------------010409070303080805060805 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Julian Elischer wrote: > In tryin gto understand rt_check_fib() (wsa rt_check()) I ended up > rewriting it to do what I thought it was trying to do.. > this stops the panics some people have seen, but allows the system to > stay up long enough to see some other problem.. > anyhow this si the patch: > > comments? > I was thinking about this a bit. rt_check_fib() drops the lock on the given rtentry in order to be able to get a lock on another rtentry that MIGHT be the same rtentry. while it is doing this, another processor could free the original rtentry. The only safw way to get around this is to hold an additional reference on the first rtentry (we don't already have one) while it is unlocked so that we can be sure that it is not actually freed if this happens. to do this safely I'd have to add a couple of new items into route.h: #define RT_TEMP_UNLOCK(_rt) do { \ RT_ADDREF(_rt); \ RT_UNLOCK(_rt); \ } while (0) #define RT_RELOCK(_rt) do { \ RT_LOCK(_rt) \ if ((_rt)->rt_refcnt <= 1) \ rtfree(_rt); \ _rt = 0; /* signal that it went away */ \ else { \ RT_REMREF(_rt); \ RT_UNLOCK(_rt); \ /* note that _rt is still valid */ \ } \ } while (0) the new version of rt_check is attached..... --------------010409070303080805060805 Content-Type: text/plain; name="rtcheck.c" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="rtcheck.c" /* * rt_check() is invoked on each layer 2 output path, prior to * encapsulating outbound packets. * * The function is mostly used to find a routing entry for the gateway, * which in some protocol families could also point to the link-level * address for the gateway itself (the side effect of revalidating the * route to the destination is rather pointless at this stage, we did it * already a moment before in the pr_output() routine to locate the ifp * and gateway to use). * * When we remove the layer-3 to layer-2 mapping tables from the * routing table, this function can be removed. * * === On input === * *dst is the address of the NEXT HOP (which coincides with the * final destination if directly reachable); * *lrt0 points to the cached route to the final destination; * *lrt is not meaningful; * fibnum is the index to the correct network fib for this packet * (*lrt0 has not ref held on it so REMREF is not needed ) * * === Operation === * If the route is marked down try to find a new route. If the route * to the gateway is gone, try to setup a new route. Otherwise, * if the route is marked for packets to be rejected, enforce that. * Note that rtalloc returns an rtentry with an extra REF that we need to lose. * * === On return === * *dst is unchanged; * *lrt0 points to the (possibly new) route to the final destination * *lrt points to the route to the next hop [LOCKED] * * Their values are meaningful ONLY if no error is returned. * * To follow this you have to remember that: * RT_REMREF reduces the reference count by 1 but doesn't check it for 0 (!) * RTFREE_LOCKED includes an RT_REMREF (or an rtfree if refs == 1) * and an RT_UNLOCK * RTFREE does an RT_LOCK and an RTFREE_LOCKED * The gwroute pointer counts as a reference on the rtentry to which it points. * so when we add it we use the ref that rtalloc gives us and when we lose it * we need to remove the reference. */ int rt_check(struct rtentry **lrt, struct rtentry **lrt0, struct sockaddr *dst) { return (rt_check_fib(lrt, lrt0, dst, 0)); } int rt_check_fib(struct rtentry **lrt, struct rtentry **lrt0, struct sockaddr *dst, u_int fibnum) { struct rtentry *rt; struct rtentry *rt0; int error; KASSERT(*lrt0 != NULL, ("rt_check")); rt0 = *lrt0; rt = NULL; /* NB: the locking here is tortuous... */ RT_LOCK(rt0); retry: if (rt0 && (rt0->rt_flags & RTF_UP) == 0) { /* Current rt0 is useless, try get a replacement. */ RT_UNLOCK(rt0); rt0 = NULL; } if (rt0 == NULL) { rt0 = rtalloc1_fib(dst, 1, 0UL, fibnum); if ((rt0 != NULL)/* && (rt0->rt_flags & RTF_UP) */) { RT_REMREF(rt0); /* don't need the reference. */ /* XXX what about interface change? */ } else { return (EHOSTUNREACH); } } /* XXX BSD/OS checks dst->sa_family != AF_NS */ if (rt0->rt_flags & RTF_GATEWAY) { if ((rt = rt0->rt_gwroute) != NULL) { RT_LOCK(rt); /* NB: gwroute */ if ((rt->rt_flags & RTF_UP) == 0) { /* gw route is dud. ignore/lose it */ RTFREE_LOCKED(rt); /* unref (&unlock) gwroute */ rt = rt0->rt_gwroute = NULL; } } if (rt == NULL) { /* NOT AN ELSE CLAUSE */ RT_TEMP_UNLOCK(rt0); /* MUST return to undo this */ /* XXX MRT link level looked up in table 0 */ rt = rtalloc1_fib(rt0->rt_gateway, 1, 0UL, fibnum); if ((rt == rt0) || (rt == NULL)) { /* the best we can do is not good enough */ if (rt) { RT_REMREF(rt); /* assumes ref > 0 */ RT_UNLOCK(rt); } RT_RELOCK(rt0); /* lose the refcount */ if (rt0) RT_UNLOCK(rt0); return (ENETUNREACH); } /* * Relock it and lose the added reference. * All sorts of things could have happenned while we * had no lock on it, so check for them. */ RT_RELOCK(rt0); if (rt0 == NULL || ((rt0->rt_flags & RTF_UP) == 0)) /* Ru-roh.. what we had is no longer any good */ goto retry; /* * While we were away, someone replaced the gateway. * Since a reference count is involved we can't just * overwrite it. */ if (rt0->rt_gwroute) { if (rt0->rt_gwroute != rt) { RT_FREE_LOCKED(rt); goto retry; } } else { rt0->rt_gwroute = rt; } } else { RT_UNLOCK(rt0); } } else { /* think of rt as having the lock from now on.. */ rt = rt0; } /* XXX why are we inspecting rmx_expire? */ if ((rt->rt_flags & RTF_REJECT) && (rt->rt_rmx.rmx_expire == 0 || time_uptime < rt->rt_rmx.rmx_expire)) { RT_UNLOCK(rt); return (rt == rt0 ? EHOSTDOWN : EHOSTUNREACH); } *lrt = rt; *lrt0 = rt0; return (0); } --------------010409070303080805060805-- From owner-freebsd-net@FreeBSD.ORG Fri Sep 5 22:52:39 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 45DD4106564A for ; Fri, 5 Sep 2008 22:52:39 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outB.internet-mail-service.net (outb.internet-mail-service.net [216.240.47.225]) by mx1.freebsd.org (Postfix) with ESMTP id 27ACC8FC12 for ; Fri, 5 Sep 2008 22:52:39 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 847A82488 for ; Fri, 5 Sep 2008 15:52:39 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 1F34F2D605F for ; Fri, 5 Sep 2008 15:52:37 -0700 (PDT) Message-ID: <48C1B83C.9000404@elischer.org> Date: Fri, 05 Sep 2008 15:52:44 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: FreeBSD Net References: <48C19568.807@elischer.org> <48C1B774.2020405@elischer.org> In-Reply-To: <48C1B774.2020405@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: rewrite of rt_check() (now rt_check_fib()) 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, 05 Sep 2008 22:52:39 -0000 Julian Elischer wrote: > Julian Elischer wrote: >> In tryin gto understand rt_check_fib() (wsa rt_check()) I ended up >> rewriting it to do what I thought it was trying to do.. >> this stops the panics some people have seen, but allows the system to >> stay up long enough to see some other problem.. >> anyhow this si the patch: >> >> comments? >> > > I was thinking about this a bit. > > rt_check_fib() drops the lock on the given rtentry in order to be able > to get a lock on another rtentry that MIGHT be the same rtentry. > > while it is doing this, another processor could free the original > rtentry. The only safw way to get around this is to hold an additional > reference on the first rtentry (we don't already have one) while it is > unlocked so that we can be sure that it is not actually freed if this > happens. > > to do this safely I'd have to add a couple of new items into route.h: > > #define RT_TEMP_UNLOCK(_rt) do { \ > RT_ADDREF(_rt); \ > RT_UNLOCK(_rt); \ > } while (0) > > #define RT_RELOCK(_rt) do { \ > RT_LOCK(_rt) \ > if ((_rt)->rt_refcnt <= 1) \ > rtfree(_rt); \ > _rt = 0; /* signal that it went away */ \ > else { \ > RT_REMREF(_rt); \ > RT_UNLOCK(_rt); duh remove that line! \ > /* note that _rt is still valid */ \ > } \ > } while (0) > > > the new version of rt_check is attached..... > > > ------------------------------------------------------------------------ > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Fri Sep 5 23:13:48 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 04862106566C for ; Fri, 5 Sep 2008 23:13:48 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outF.internet-mail-service.net (outf.internet-mail-service.net [216.240.47.229]) by mx1.freebsd.org (Postfix) with ESMTP id D653C8FC12 for ; Fri, 5 Sep 2008 23:13:47 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 94F4F2425 for ; Fri, 5 Sep 2008 16:13:48 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id D90B42D6040 for ; Fri, 5 Sep 2008 16:13:46 -0700 (PDT) Message-ID: <48C1BD31.6090804@elischer.org> Date: Fri, 05 Sep 2008 16:13:53 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: FreeBSD Net References: <48C19568.807@elischer.org> <48C1B774.2020405@elischer.org> <48C1B83C.9000404@elischer.org> In-Reply-To: <48C1B83C.9000404@elischer.org> Content-Type: multipart/mixed; boundary="------------060105090400010304060507" Subject: Re: rewrite of rt_check() (now rt_check_fib()) 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, 05 Sep 2008 23:13:48 -0000 This is a multi-part message in MIME format. --------------060105090400010304060507 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Julian Elischer wrote: > Julian Elischer wrote: >> Julian Elischer wrote: >>> In tryin gto understand rt_check_fib() (wsa rt_check()) I ended up >>> rewriting it to do what I thought it was trying to do.. >>> this stops the panics some people have seen, but allows the system to >>> stay up long enough to see some other problem.. >>> anyhow this si the patch: >>> >>> comments? >>> >> >> I was thinking about this a bit. >> >> rt_check_fib() drops the lock on the given rtentry in order to be able >> to get a lock on another rtentry that MIGHT be the same rtentry. >> >> while it is doing this, another processor could free the original >> rtentry. The only safw way to get around this is to hold an additional >> reference on the first rtentry (we don't already have one) while it is >> unlocked so that we can be sure that it is not actually freed if this >> happens. >> >> to do this safely I'd have to add a couple of new items into route.h: this time with less (I hope) bugs... new macros... #define RT_TEMP_UNLOCK(_rt) do { \ RT_ADDREF(_rt); \ RT_UNLOCK(_rt); \ } while (0) #define RT_RELOCK(_rt) do { \ RT_LOCK(_rt) \ if ((_rt)->rt_refcnt <= 1) \ rtfree(_rt); \ _rt = 0; /* signal that it went away */ \ else { \ RT_REMREF(_rt); \ /* note that _rt is still valid */ \ } \ } while (0) with (better) code attached: --------------060105090400010304060507 Content-Type: text/plain; name="rt_check.c" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="rt_check.c" /* * rt_check() is invoked on each layer 2 output path, prior to * encapsulating outbound packets. * * The function is mostly used to find a routing entry for the gateway, * which in some protocol families could also point to the link-level * address for the gateway itself (the side effect of revalidating the * route to the destination is rather pointless at this stage, we did it * already a moment before in the pr_output() routine to locate the ifp * and gateway to use). * * When we remove the layer-3 to layer-2 mapping tables from the * routing table, this function can be removed. * * === On input === * *dst is the address of the NEXT HOP (which coincides with the * final destination if directly reachable); * *lrt0 points to the cached route to the final destination; * *lrt is not meaningful; * fibnum is the index to the correct network fib for this packet * (*lrt0 has not ref held on it so REMREF is not needed ) * * === Operation === * If the route is marked down try to find a new route. If the route * to the gateway is gone, try to setup a new route. Otherwise, * if the route is marked for packets to be rejected, enforce that. * Note that rtalloc returns an rtentry with an extra REF that we need to lose. * * === On return === * *dst is unchanged; * *lrt0 points to the (possibly new) route to the final destination * *lrt points to the route to the next hop [LOCKED] * * Their values are meaningful ONLY if no error is returned. * * To follow this you have to remember that: * RT_REMREF reduces the reference count by 1 but doesn't check it for 0 (!) * RTFREE_LOCKED includes an RT_REMREF (or an rtfree if refs == 1) * and an RT_UNLOCK * RTFREE does an RT_LOCK and an RTFREE_LOCKED * The gwroute pointer counts as a reference on the rtentry to which it points. * so when we add it we use the ref that rtalloc gives us and when we lose it * we need to remove the reference. */ int rt_check(struct rtentry **lrt, struct rtentry **lrt0, struct sockaddr *dst) { return (rt_check_fib(lrt, lrt0, dst, 0)); } int rt_check_fib(struct rtentry **lrt, struct rtentry **lrt0, struct sockaddr *dst, u_int fibnum) { struct rtentry *rt; struct rtentry *rt0; int error; KASSERT(*lrt0 != NULL, ("rt_check")); rt0 = *lrt0; rt = NULL; /* NB: the locking here is tortuous... */ RT_LOCK(rt0); retry: if (rt0 && (rt0->rt_flags & RTF_UP) == 0) { /* Current rt0 is useless, try get a replacement. */ RT_UNLOCK(rt0); rt0 = NULL; } if (rt0 == NULL) { rt0 = rtalloc1_fib(dst, 1, 0UL, fibnum); if (rt0 == NULL) { return (EHOSTUNREACH); } RT_REMREF(rt0); /* don't need the reference. */ } if (rt0->rt_flags & RTF_GATEWAY) { if ((rt = rt0->rt_gwroute) != NULL) { RT_LOCK(rt); /* NB: gwroute */ if ((rt->rt_flags & RTF_UP) == 0) { /* gw route is dud. ignore/lose it */ RTFREE_LOCKED(rt); /* unref (&unlock) gwroute */ rt = rt0->rt_gwroute = NULL; } } if (rt == NULL) { /* NOT AN ELSE CLAUSE */ RT_TEMP_UNLOCK(rt0); /* MUST return to undo this */ rt = rtalloc1_fib(rt0->rt_gateway, 1, 0UL, fibnum); if ((rt == rt0) || (rt == NULL)) { /* the best we can do is not good enough */ if (rt) { RT_REMREF(rt); /* assumes ref > 0 */ RT_UNLOCK(rt); } RT_FREE(rt0); /* lock, unref, (unlock) */ return (ENETUNREACH); } /* * Relock it and lose the added reference. * All sorts of things could have happenned while we * had no lock on it, so check for them. */ RT_RELOCK(rt0); if (rt0 == NULL || ((rt0->rt_flags & RTF_UP) == 0)) /* Ru-roh.. what we had is no longer any good */ goto retry; /* * While we were away, someone replaced the gateway. * Since a reference count is involved we can't just * overwrite it. */ if (rt0->rt_gwroute) { if (rt0->rt_gwroute != rt) { RT_FREE_LOCKED(rt); goto retry; } } else { rt0->rt_gwroute = rt; } } RT_LOCK_ASSERT(rt); RT_UNLOCK(rt0); } else { /* think of rt as having the lock from now on.. */ rt = rt0; } /* XXX why are we inspecting rmx_expire? */ if ((rt->rt_flags & RTF_REJECT) && (rt->rt_rmx.rmx_expire == 0 || time_uptime < rt->rt_rmx.rmx_expire)) { RT_UNLOCK(rt); return (rt == rt0 ? EHOSTDOWN : EHOSTUNREACH); } *lrt = rt; *lrt0 = rt0; return (0); } --------------060105090400010304060507-- From owner-freebsd-net@FreeBSD.ORG Sat Sep 6 00:46:39 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C98A910656D5 for ; Sat, 6 Sep 2008 00:46:39 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.185]) by mx1.freebsd.org (Postfix) with ESMTP id 3786B8FC17 for ; Sat, 6 Sep 2008 00:46:37 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by ti-out-0910.google.com with SMTP id d27so371165tid.3 for ; Fri, 05 Sep 2008 17:46:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from :to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=0w4hV72ysMs5JkAcsqa7sl9q7U3EHxo579BaxhIjgOg=; b=WBJ7f1gKj1dE94N0kuiDFQ+Ekeup4YRDV0tdTaKbxeHpGgtxZWlsoMFEpijjEQw6GR rJxmB+ptd4Y9clvhiZoaEgUehTbY1iiN49i6pOUDiUWZ2QFxmxuk2bSZqRB68WUwknuL 9TM9wBdsviN04d69YmkhVag7P/7sPRQMy1DRA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=YBVyJLI8/fvzCYofpHrlHjnqxXpqn18bVNZx+ddpdtMvPJVnzJI9boymg0P+rrwnoT o73i35EKNmGTwtTOIIjk90hqHKlnKWO2aahGV8QAJmCf5BfBRpq6Xab0xaqsTdJKPuiw K905eQ9AdB3Za37rcPaVL+BqDZOsZvnFr5yrc= Received: by 10.110.47.17 with SMTP id u17mr15804400tiu.49.1220661994798; Fri, 05 Sep 2008 17:46:34 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id a14sm1969621tia.0.2008.09.05.17.46.31 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 05 Sep 2008 17:46:33 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id m860kTxO070076 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 6 Sep 2008 09:46:29 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id m860kR6K070075; Sat, 6 Sep 2008 09:46:27 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Sat, 6 Sep 2008 09:46:27 +0900 From: Pyun YongHyeon To: Milan Obuch Message-ID: <20080906004627.GA69867@cdnetworks.co.kr> References: <200809050945.09276.freebsd-net@dino.sk> <20080905082322.GA66951@cdnetworks.co.kr> <200809051643.52950.freebsd-net@dino.sk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200809051643.52950.freebsd-net@dino.sk> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org Subject: Re: MSI Wind Notebook's network interfaces X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Sep 2008 00:46:40 -0000 On Fri, Sep 05, 2008 at 04:43:51PM +0200, Milan Obuch wrote: > On Friday 05 September 2008 10:23:22 Pyun YongHyeon wrote: > > On Fri, Sep 05, 2008 at 09:45:08AM +0200, Milan Obuch wrote: > > [ snip ] > > > > In 7.0-RELEASE wired network interface did not work, but after upgrading > > > to 7-STABLE (now 7.1-PRERELEASE) it work with re driver. There is just > > > one small uglyness - it's link level address (MAC) is 00:00:00:00:00:00. > > > Needless to say, Windows initializes this to 00:1d:92:59:f5:8b. I can > > > change it with 'ifconfig re0 ether 00:1d:92:59:f5:8b', but I would > > > rather let the driver to find the correct MAC. > > [ snip ] > > > > dmesg (part of verbose boot) > > > re0: port 0xc000-0xc0ff > > > mem 0xffd10000-0xffd10fff,0xffd00000-0xffd0ffff irq 16 at device 0.0 on > > > pci1 re0: Reserved 0x1000 bytes for rid 0x18 type 3 at 0xffd10000 > > > re0: MSI count : 1 > > > re0: Chip rev. 0x34800000 > > > re0: MAC rev. 0x00200000 > > > miibus0: on re0 > > > rlphy0: PHY 1 on miibus0 > > > rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > > > re0: bpf attached > > > re0: [MPSAFE] > > > re0: [FILTER] > > > > > > When not booting verbose, there is also one line telling > > > re0: turning off MSI enable bit. > > > > re(4) cleared MSI enable bit of configuration register as MSI > > wouldn't be used. You can ignore this. > > > > OK, but what surprised me a bit was the fact this line is not present in dmesg > when booting verbose. I would expect all lines from normal boot in verbose > boot... > That MSI information is stored in EEPROM. So you wouldn't see the message again if MSI enable bit was already cleard. Since re(4) clears the bit subsequent booting wouldn't touch the MSI enable bit in EEPROM. > > > This netbook has also wireless interface, but this one does not get > > > detected (or I have no driver for it), in dmesg there is only line > > > telling pci2: at device 0.0 (no driver attached) > > > > > > and relevant part of pciconf -lcv is > > > none0@pci0:2:0:0: class=0x028000 card=0x68941462 chip=0x819910ec > > > rev=0x22 hdr=0x00 > > > vendor = 'Realtek Semiconductor' > > > class = network > > > cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 > > > cap 05[50] = MSI supports 1 message, 64 bit > > > cap 10[70] = PCI-Express 1 legacy endpoint > > > > > > While currently I have no urge need for wireless connectivity, in the > > > long run I would like to use it. Currently I can't change card (probably > > > minipci) as netbook is under warranty, with 'warranty sticker - void if > > > tampered' over screw. > > > > > > If anybody had some idea how to fix MAC address initialization for wired > > > > Would you try attached patch? > > > > I tried on freshly csup'ped head and it works. Ethernet link address is now > correctly set. Great! It looks like a kind of magic at first glance :) > I've commited the patch to HEAD(r182808). Thanks for your testing! -- Regards, Pyun YongHyeon From owner-freebsd-net@FreeBSD.ORG Sat Sep 6 06:00:12 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 879D11065671 for ; Sat, 6 Sep 2008 06:00:12 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 7B95C8FC17 for ; Sat, 6 Sep 2008 06:00:12 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m8660CNk072987 for ; Sat, 6 Sep 2008 06:00:12 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m8660CUv072986; Sat, 6 Sep 2008 06:00:12 GMT (envelope-from gnats) Date: Sat, 6 Sep 2008 06:00:12 GMT Message-Id: <200809060600.m8660CUv072986@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: freebsd-bridge-sep08@oldach.net (Helge Oldach) Cc: Subject: Re: kern/127052: Still bridge issues - with L2 protocols such as PPPoE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Helge Oldach List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Sep 2008 06:00:12 -0000 The following reply was made to PR kern/127052; it has been noted by GNATS. From: freebsd-bridge-sep08@oldach.net (Helge Oldach) To: FreeBSD-gnats-submit@FreeBSD.org, freebsd-bugs@FreeBSD.org Cc: Subject: Re: kern/127052: Still bridge issues - with L2 protocols such as PPPoE Date: Sat, 6 Sep 2008 07:43:42 +0200 (CEST) I have tested Eygenes patch and it works as expected on 6-STABLE. However the behaviour is a little bit strange: The sysctl is of by default. When enabling it, nothing happens. The bridge's MAC still is the random MAC chosen upon boot. Even toggling the bridge interface down/up doesn't change it. The bridge's MAC is inherited only when a member interface is added or deleted. Essentially this sysctl must be set at boot time, e.g. in /etc/sysctl.conf to make it work consistently. Further, it is a global sysctl that applies to *all* bridge interfaces identically. It is not possible to have one bridge with inheritance, and another without. Philip explained that the main rationale for MAC inheritance was to make DHCP consistent over reboots. This can be simply achieved by a trivial ifconfig_bridge0="link 66:fc:df:e2:3f:f5 up" (or similar) in /etc/rc.conf. There is no need to change code at all to achieve the desired effect, and we still have full flexibility, even with multiple bridges. (To simplify mass deployment, one can seed the MAC in the above command from a file created upon initial boot.) I would therefore mandate to back out the bridge inheritance stuff completely. Helge From owner-freebsd-net@FreeBSD.ORG Sat Sep 6 06:04:07 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 67CAC106567A for ; Sat, 6 Sep 2008 06:04:07 +0000 (UTC) (envelope-from freebsd-net@dino.sk) Received: from loki.netlab.sk (loki.netlab.sk [84.245.65.11]) by mx1.freebsd.org (Postfix) with ESMTP id DA57B8FC1B for ; Sat, 6 Sep 2008 06:04:06 +0000 (UTC) (envelope-from freebsd-net@dino.sk) Received: from via.dino.sk (home.dino.sk [84.245.95.252]) (AUTH: PLAIN milan, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by loki.netlab.sk with esmtp; Sat, 06 Sep 2008 08:02:33 +0200 id 0002E010.48C21CF9.000117CE From: Milan Obuch To: freebsd-net@freebsd.org, pyunyh@gmail.com Date: Sat, 6 Sep 2008 08:03:52 +0200 User-Agent: KMail/1.9.7 References: <200809050945.09276.freebsd-net@dino.sk> <200809051643.52950.freebsd-net@dino.sk> <20080906004627.GA69867@cdnetworks.co.kr> In-Reply-To: <20080906004627.GA69867@cdnetworks.co.kr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200809060803.53293.freebsd-net@dino.sk> Cc: Subject: Re: MSI Wind Notebook's network interfaces 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, 06 Sep 2008 06:04:07 -0000 On Saturday 06 September 2008 02:46:27 Pyun YongHyeon wrote: [ snip ] > > > > When not booting verbose, there is also one line telling > > > > re0: turning off MSI enable bit. > > > > > > re(4) cleared MSI enable bit of configuration register as MSI > > > wouldn't be used. You can ignore this. > > > > OK, but what surprised me a bit was the fact this line is not present in > > dmesg when booting verbose. I would expect all lines from normal boot in > > verbose boot... > > That MSI information is stored in EEPROM. So you wouldn't see the > message again if MSI enable bit was already cleard. Since re(4) > clears the bit subsequent booting wouldn't touch the MSI enable bit > in EEPROM. > Now that's clear to me. [ snip ] > > > > If anybody had some idea how to fix MAC address initialization for > > > > wired > > > > > > Would you try attached patch? > > > > I tried on freshly csup'ped head and it works. Ethernet link address is > > now correctly set. Great! It looks like a kind of magic at first glance > > :) > > I've commited the patch to HEAD(r182808). > > Thanks for your testing! It was my pleasure and I would like to express my thanks for your great work. If you will need in future some more testing with this hardware, just drop me a line. Just a side note, will this patch be MFS'ed into 7-STABLE in short timeframe? Regards, Milan From owner-freebsd-net@FreeBSD.ORG Sat Sep 6 06:43:44 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C60B21065677 for ; Sat, 6 Sep 2008 06:43:44 +0000 (UTC) (envelope-from freebsd-net@dino.sk) Received: from loki.netlab.sk (loki.netlab.sk [84.245.65.11]) by mx1.freebsd.org (Postfix) with ESMTP id 466268FC08 for ; Sat, 6 Sep 2008 06:43:44 +0000 (UTC) (envelope-from freebsd-net@dino.sk) Received: from via.dino.sk (home.dino.sk [84.245.95.252]) (AUTH: PLAIN milan, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by loki.netlab.sk with esmtp; Sat, 06 Sep 2008 08:42:12 +0200 id 0002E010.48C22644.000118FE From: Milan Obuch To: freebsd-net@freebsd.org, "Kevin Downey" Date: Sat, 6 Sep 2008 08:43:34 +0200 User-Agent: KMail/1.9.7 References: <200809050945.09276.freebsd-net@dino.sk> <200809051643.52950.freebsd-net@dino.sk> <1d3ed48c0809050913h7a9b69eas14476c9e9c7071d5@mail.gmail.com> In-Reply-To: <1d3ed48c0809050913h7a9b69eas14476c9e9c7071d5@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200809060843.35213.freebsd-net@dino.sk> Cc: Subject: Re: MSI Wind Notebook's network interfaces 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, 06 Sep 2008 06:43:44 -0000 On Friday 05 September 2008 18:13:45 Kevin Downey wrote: > On Fri, Sep 5, 2008 at 7:43 AM, Milan Obuch wrote: > > [ snip ] > > Could anybody comment on wireless interface? > > I could not get the internal wifi to work with ndis wrapper. It > appears that using the rtw driver netbsd, openbsd, and dragonflybsd > all support this chipset. I found a (polish?) webpage with a very > preliminary attempt at porting the rtw driver. The author of the port > said it doesn't really work. > > I just gave up and bought a usb wifi stick. Hm, I downloaded install CDs for NetBSD-4.0 and OpenBSD-4.3, and they do not show working wireless interface/no driver attached. How did you try it? Do you have any reference, alternatively? Wireless interface is not top priority for me at a moment, but if it were not too hard, I will try. My notebook is Wind U100 series... is yours similar or perhaps the same? Regards, Milan From owner-freebsd-net@FreeBSD.ORG Sat Sep 6 11:17:36 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DBD271065682 for ; Sat, 6 Sep 2008 11:17:36 +0000 (UTC) (envelope-from bennett@cs.niu.edu) Received: from mp.cs.niu.edu (mp.cs.niu.edu [131.156.145.41]) by mx1.freebsd.org (Postfix) with ESMTP id B5CAC8FC39 for ; Sat, 6 Sep 2008 11:17:36 +0000 (UTC) (envelope-from bennett@cs.niu.edu) Received: from mp.cs.niu.edu (bennett@localhost [127.0.0.1]) by mp.cs.niu.edu (8.14.3/8.14.3) with ESMTP id m86AIk0E006136 for ; Sat, 6 Sep 2008 05:18:46 -0500 (CDT) Date: Sat, 6 Sep 2008 05:18:45 -0500 (CDT) From: Scott Bennett Message-Id: <200809061018.m86AIje1006135@mp.cs.niu.edu> To: freebsd-net@freebsd.org Subject: TCP connections hanging in FIN_WAIT_1 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, 06 Sep 2008 11:17:36 -0000 I'm running FreeBSD 6.3-STABLE, compiled with updates as of 13 Aug. 2008, and I'm seeing TCP connections that have been in FIN_WAIT_1 state for at least eleven *hours*. It has been years since I last read all the specs on TCP close processing, but my recollection is that the entire sequence was limited to only two or three minutes. I couldn't find a bug report, but that proves nothing. Does anyone know of such a bug? Or some weird condition I should look for that might cause TCP connections to get stuck in the closing sequence somehow? The hardware configuration is a Dell Inspiron XPS with a Broadcom BCM5705 A1 adaptor, ASIC rev. 0x3001, (bge driver) for 10/100/1000 Mb/s connected to a Comcast/RCA cable modem at 100 Mb/s. Thanks in advance for any information you may have. Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at cs.niu.edu * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * ********************************************************************** From owner-freebsd-net@FreeBSD.ORG Sat Sep 6 15:43:50 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A1EC1065671 for ; Sat, 6 Sep 2008 15:43:50 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 480658FC1A for ; Sat, 6 Sep 2008 15:43:50 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from Macintosh-4.local ([10.0.0.194]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id m86FhhJA029041 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 6 Sep 2008 08:43:44 -0700 (PDT) (envelope-from sam@freebsd.org) Message-ID: <48C2A52F.1080705@freebsd.org> Date: Sat, 06 Sep 2008 08:43:43 -0700 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Milan Obuch References: <200809050945.09276.freebsd-net@dino.sk> <200809051643.52950.freebsd-net@dino.sk> <1d3ed48c0809050913h7a9b69eas14476c9e9c7071d5@mail.gmail.com> <200809060843.35213.freebsd-net@dino.sk> In-Reply-To: <200809060843.35213.freebsd-net@dino.sk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-DCC--Metrics: ebb.errno.com; whitelist Cc: freebsd-net@freebsd.org, Kevin Downey Subject: Re: MSI Wind Notebook's network interfaces 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, 06 Sep 2008 15:43:50 -0000 Milan Obuch wrote: > On Friday 05 September 2008 18:13:45 Kevin Downey wrote: >> On Fri, Sep 5, 2008 at 7:43 AM, Milan Obuch wrote: >>> [ snip ] >>> Could anybody comment on wireless interface? >> I could not get the internal wifi to work with ndis wrapper. It >> appears that using the rtw driver netbsd, openbsd, and dragonflybsd >> all support this chipset. I found a (polish?) webpage with a very >> preliminary attempt at porting the rtw driver. The author of the port >> said it doesn't really work. >> >> I just gave up and bought a usb wifi stick. > > Hm, I downloaded install CDs for NetBSD-4.0 and OpenBSD-4.3, and they do not > show working wireless interface/no driver attached. How did you try it? Do > you have any reference, alternatively? > > Wireless interface is not top priority for me at a moment, but if it were not > too hard, I will try. > > My notebook is Wind U100 series... is yours similar or perhaps the same? rtw supports only an old 11b only part. If you've really got a RealTek wireless part in this laptop then it's not supported by any bsd driver I know of. There's a linux driver of unknown quality that someone can use to build a bsd driver but given how cheap wireless parts are your best bet is to just replace the card. Sam From owner-freebsd-net@FreeBSD.ORG Sat Sep 6 16:19:08 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 946A9106564A for ; Sat, 6 Sep 2008 16:19:08 +0000 (UTC) (envelope-from freebsd-net@dino.sk) Received: from loki.netlab.sk (loki.netlab.sk [84.245.65.11]) by mx1.freebsd.org (Postfix) with ESMTP id 1591F8FC14 for ; Sat, 6 Sep 2008 16:19:06 +0000 (UTC) (envelope-from freebsd-net@dino.sk) Received: from via.dino.sk (home.dino.sk [84.245.95.252]) (AUTH: PLAIN milan, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by loki.netlab.sk with esmtp; Sat, 06 Sep 2008 18:17:28 +0200 id 0002E00D.48C2AD18.00012713 From: Milan Obuch To: freebsd-net@freebsd.org Date: Sat, 6 Sep 2008 18:18:52 +0200 User-Agent: KMail/1.9.7 References: <200809050945.09276.freebsd-net@dino.sk> <200809060843.35213.freebsd-net@dino.sk> <48C2A52F.1080705@freebsd.org> In-Reply-To: <48C2A52F.1080705@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200809061818.52700.freebsd-net@dino.sk> Cc: Sam Leffler Subject: Re: MSI Wind Notebook's network interfaces 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, 06 Sep 2008 16:19:08 -0000 On Saturday 06 September 2008 17:43:43 Sam Leffler wrote: [ snip ] > > Hm, I downloaded install CDs for NetBSD-4.0 and OpenBSD-4.3, and they do > > not show working wireless interface/no driver attached. How did you try > > it? Do you have any reference, alternatively? > > > > Wireless interface is not top priority for me at a moment, but if it were > > not too hard, I will try. > > > > My notebook is Wind U100 series... is yours similar or perhaps the same? > > rtw supports only an old 11b only part. If you've really got a RealTek > wireless part in this laptop then it's not supported by any bsd driver I > know of. There's a linux driver of unknown quality that someone can use > to build a bsd driver but given how cheap wireless parts are your best > bet is to just replace the card. > Unfortunately, I will not be allowed to do it until warranty expires... but it's not top priority for me. Judging from Windows driver, this card is b/g capable, so no luck now. No trouble, I need other things get working. Regards, Milan From owner-freebsd-net@FreeBSD.ORG Sat Sep 6 23:16:43 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78ABF1065677; Sat, 6 Sep 2008 23:16:43 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 566478FC1B; Sat, 6 Sep 2008 23:16:43 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (remko@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m86NGhYO000641; Sat, 6 Sep 2008 23:16:43 GMT (envelope-from remko@freefall.freebsd.org) Received: (from remko@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m86NGhDj000637; Sat, 6 Sep 2008 23:16:43 GMT (envelope-from remko) Date: Sat, 6 Sep 2008 23:16:43 GMT Message-Id: <200809062316.m86NGhDj000637@freefall.freebsd.org> To: czeryna@gmail.com, remko@FreeBSD.org, freebsd-i386@FreeBSD.org, freebsd-net@FreeBSD.org From: remko@FreeBSD.org Cc: Subject: Re: kern/127145: [wi]: prism (wi) driver crash at bigger traffic 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, 06 Sep 2008 23:16:43 -0000 Old Synopsis: prism (wi) driver crash at bigger traffic New Synopsis: [wi]: prism (wi) driver crash at bigger traffic State-Changed-From-To: open->feedback State-Changed-By: remko State-Changed-When: Sat Sep 6 23:15:46 UTC 2008 State-Changed-Why: Ask for feedback: Can you report whether 7.x still has this issue? Responsible-Changed-From-To: freebsd-i386->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Sat Sep 6 23:15:46 UTC 2008 Responsible-Changed-Why: change to -net, wi is a networking driver. http://www.freebsd.org/cgi/query-pr.cgi?pr=127145