From owner-freebsd-net@FreeBSD.ORG Sun Jan 24 03:42:57 2010 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 8F793106566B for ; Sun, 24 Jan 2010 03:42:57 +0000 (UTC) (envelope-from list@sheringeorge.co.cc) Received: from mail-px0-f183.google.com (mail-px0-f183.google.com [209.85.216.183]) by mx1.freebsd.org (Postfix) with ESMTP id 73A268FC0A for ; Sun, 24 Jan 2010 03:42:57 +0000 (UTC) Received: by pxi13 with SMTP id 13so1720119pxi.3 for ; Sat, 23 Jan 2010 19:42:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.214.7 with SMTP id r7mr3482593rvq.85.1264302979251; Sat, 23 Jan 2010 19:16:19 -0800 (PST) Date: Sun, 24 Jan 2010 08:46:19 +0530 Message-ID: <7f14551c1001231916s1c142b21j916ae406ea71bd97@mail.gmail.com> From: Sherin George To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Strange network issue in freebsd 8 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, 24 Jan 2010 03:42:57 -0000 Hello, I am facing some sort of strange network issue in a freebsd server occasionally. OS: FreeBSD 8.0-RELEASE - amd64 Now, I have updated to FreeBSD 8.0-RELEASE-p2 The servers loses network connection once in a few days. I logged into console and verified that network is up. I even restarted network service using following command. /etc/rc.d/netif restart Still, it didn't fix. I checked /var/log/messages, but I am not getting any clue. ============== Jan 19 12:10:20 myserver kernel: GEOM_MIRROR: Device gm0: rebuilding provider ad0 finished. Jan 19 20:20:23 myserver nfsd[732]: select failed: Interrupted system call Jan 19 20:21:07 myserver nfsd[732]: select failed: Interrupted system call Jan 23 02:14:33 myserver login: ROOT LOGIN (root) ON ttyv0 Jan 23 02:19:51 myserver kernel: ifa_del_loopback_route: deletion failed Jan 23 02:19:57 myserver kernel: em0: link state changed to DOWN Jan 23 02:20:02 myserver kernel: em0: link state changed to UP Jan 23 02:29:58 myserver reboot: rebooted by root Jan 23 02:29:58 myserver syslogd: exiting on signal 15 Jan 23 02:31:31 myserver syslogd: kernel boot file is /boot/kernel/kernel Jan 23 02:31:31 myserver kernel: Copyright (c) 1992-2009 The FreeBSD Project. Jan 23 02:31:31 myserver kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Jan 23 02:31:31 myserver kernel: The Regents of the University of California. All rights reserved. Jan 23 02:31:31 myserver kernel: FreeBSD is a registered trademark of The FreeBSD Foundation. Jan 23 02:31:31 myserver kernel: FreeBSD 8.0-RELEASE #0: Sat Nov 21 15:02:08 UTC 2009 Jan 23 02:31:31 myserver kernel: root@mason.cse.buffalo.edu: /usr/obj/usr/src/sys/GENERIC Jan 23 02:31:31 myserver kernel: Timecounter "i8254" frequency 1193182 Hz quality 0 ============== Network, TCP stack all were up. It was pinging gateway even. But, traceroute was not going beyond gateway. I believe the issue is not related to anything outside server since a reboot always fixes the issue. I will be grateful for any advice that can help me in troubleshooting this problem. -- Best Regards, Sherin From owner-freebsd-net@FreeBSD.ORG Sun Jan 24 10:52:34 2010 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 6E1A8106566B; Sun, 24 Jan 2010 10:52:34 +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 452038FC18; Sun, 24 Jan 2010 10:52:34 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o0OAqYps032836; Sun, 24 Jan 2010 10:52:34 GMT (envelope-from remko@freefall.freebsd.org) Received: (from remko@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o0OAqY3Y032832; Sun, 24 Jan 2010 10:52:34 GMT (envelope-from remko) Date: Sun, 24 Jan 2010 10:52:34 GMT Message-Id: <201001241052.o0OAqY3Y032832@freefall.freebsd.org> To: remko@FreeBSD.org, freebsd-net@FreeBSD.org, syrinx@FreeBSD.org From: remko@FreeBSD.org Cc: Subject: Re: kern/142392: [panic] rtadvd(8) triggers kernel panic when started for a hardware WLAN interface 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, 24 Jan 2010 10:52:34 -0000 Synopsis: [panic] rtadvd(8) triggers kernel panic when started for a hardware WLAN interface Responsible-Changed-From-To: freebsd-net->syrinx Responsible-Changed-By: remko Responsible-Changed-When: Sun Jan 24 10:52:33 UTC 2010 Responsible-Changed-Why: Shteryana has a patch, assign to her. http://www.freebsd.org/cgi/query-pr.cgi?pr=142392 From owner-freebsd-net@FreeBSD.ORG Sun Jan 24 18:49:39 2010 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 E63961065693; Sun, 24 Jan 2010 18:49:39 +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 BDE208FC18; Sun, 24 Jan 2010 18:49:39 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o0OIndcd039841; Sun, 24 Jan 2010 18:49:39 GMT (envelope-from remko@freefall.freebsd.org) Received: (from remko@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o0OIndRQ039837; Sun, 24 Jan 2010 18:49:39 GMT (envelope-from remko) Date: Sun, 24 Jan 2010 18:49:39 GMT Message-Id: <201001241849.o0OIndRQ039837@freefall.freebsd.org> To: remko@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: remko@FreeBSD.org Cc: Subject: Re: kern/143163: Radiotap bug in ieee80211_sta.c:sta_input 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, 24 Jan 2010 18:49:40 -0000 Synopsis: Radiotap bug in ieee80211_sta.c:sta_input Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Sun Jan 24 18:49:29 UTC 2010 Responsible-Changed-Why: Assign to networking guys. http://www.freebsd.org/cgi/query-pr.cgi?pr=143163 From owner-freebsd-net@FreeBSD.ORG Mon Jan 25 10:30:57 2010 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 2865D106566B; Mon, 25 Jan 2010 10:30:57 +0000 (UTC) (envelope-from tibor.vidok@ericsson.com) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by mx1.freebsd.org (Postfix) with ESMTP id 770358FC0C; Mon, 25 Jan 2010 10:30:55 +0000 (UTC) X-AuditID: c1b4fb24-b7c57ae000002bb1-d1-4b5d6f586a5a Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 4D.FD.11185.85F6D5B4; Mon, 25 Jan 2010 11:15:52 +0100 (CET) Received: from [159.107.198.158] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.92) with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 25 Jan 2010 11:15:51 +0100 Message-ID: <4B5D6F50.2090900@ericsson.com> Date: Mon, 25 Jan 2010 11:15:44 +0100 From: Tibor Vidok User-Agent: Thunderbird 2.0.0.23 (X11/20090812) MIME-Version: 1.0 To: "freebsd-net@freebsd.org" , X-Enigmail-Version: 0.96.0 Content-Type: multipart/mixed; boundary="------------030706020709050603030407" X-Brightmail-Tracker: AAAAAA== Cc: Subject: Legacy interrupt registration in e1000 (em and igb) 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, 25 Jan 2010 10:30:57 -0000 --------------030706020709050603030407 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Jack and all, Few month before I've send a PR (see bellow) about interrupt setup in em driver. Now I run into the same problem with igb too. It seems that I'm the one using such an old interrupt mechanism with new chips... So the problem is that when one tries to register legacy mode interrupts, NULL is passed to bus_setup_intr as handler. Jack: Please check my attached path and apply it if you think so. Original PR was the following: Number:140728 Category:kern Synopsis:[em] [patch] Fast irq registration in em driver Have a nice day, Tibor -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFLXW9QCwkLbqzjZAIRApe6AJ9310xDauVwNFsDd9cq5GYop2GlzwCg2y5T v54NC8n6XeAlg0VhB+jDaHE= =vSx/ -----END PGP SIGNATURE----- --------------030706020709050603030407 Content-Type: text/x-patch; name="legacy-intr.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="legacy-intr.patch" Index: if_igb.c =================================================================== --- if_igb.c (revision 202964) +++ if_igb.c (working copy) @@ -2075,7 +2075,7 @@ taskqueue_start_threads(&adapter->tq, 1, PI_NET, "%s taskq", device_get_nameunit(adapter->dev)); if ((error = bus_setup_intr(dev, adapter->res, - INTR_TYPE_NET | INTR_MPSAFE, igb_irq_fast, NULL, + INTR_TYPE_NET | INTR_MPSAFE, NULL, igb_irq_fast, adapter, &adapter->tag)) != 0) { device_printf(dev, "Failed to register fast interrupt " "handler: %d\n", error); Index: if_em.c =================================================================== --- if_em.c (revision 202964) +++ if_em.c (working copy) @@ -2787,7 +2787,7 @@ INTR_TYPE_NET | INTR_FAST, em_irq_fast, adapter, #else if ((error = bus_setup_intr(dev, adapter->res[0], - INTR_TYPE_NET, em_irq_fast, NULL, adapter, + INTR_TYPE_NET, NULL, em_irq_fast, adapter, #endif &adapter->tag[0])) != 0) { device_printf(dev, "Failed to register fast interrupt " --------------030706020709050603030407 Content-Type: application/pgp-signature; name="legacy-intr.patch.sig" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="legacy-intr.patch.sig" iD8DBQBLXW9QCwkLbqzjZAIRAmfZAKDzlEed9SOgmutK14cF14b/nBJ1YgCfWLQLKXL7fMIt mtONvrzwEJdKrXM= --------------030706020709050603030407-- From owner-freebsd-net@FreeBSD.ORG Mon Jan 25 11:07:06 2010 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 701641065693 for ; Mon, 25 Jan 2010 11:07:06 +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 5C3F08FC30 for ; Mon, 25 Jan 2010 11:07:06 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o0PB76Bn038843 for ; Mon, 25 Jan 2010 11:07:06 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o0PB75N3038841 for freebsd-net@FreeBSD.org; Mon, 25 Jan 2010 11:07:05 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 25 Jan 2010 11:07:05 GMT Message-Id: <201001251107.o0PB75N3038841@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, 25 Jan 2010 11:07:06 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/143163 net [ieee80211] [patch] Radiotap bug in ieee80211_sta.c:st o conf/143079 net [hostapd] startup missing multi wlan functionality o kern/143074 net [wi]: wi driver triggers panic o kern/143046 net [mxge] [panic] panics since mxge(4) update o kern/143034 net [panic] system reboots itself in tcp code [regression] o kern/142907 net [wpi] if_wpi unstable on ibm/lenovo x60 -- suspect fir o kern/142877 net [hang] network-related repeatable 8.0-STABLE hard hang o kern/142774 net Problem with outgoing connections on interface with mu o kern/142766 net [ipw] [regression] ipw(4) with Intel PRO/wireless 2100 o bin/142547 net wpa_supplicant(8) drops connection on key renegotiatio o kern/142518 net [em] [lagg] Problem on 8.0-STABLE with em and lagg o kern/142019 net [em] em needs "ifconfig em0 down up" when link was gon o kern/142018 net [iwi] [patch] Possibly wrong interpretation of beacon- o kern/141861 net [wi] data garbled with WEP and wi(4) with Prism 2.5 o kern/141843 net [em] [vlan] Intel txcsum and assigned vlan invoke wron o kern/141777 net [rum] [patch] Support usbdevs / rum(4) for Buffalo WLI f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, o kern/141720 net [sctp] [lor] [hang] sctp-create vs. sctp-it causes sys o kern/141698 net [sctp] [panic] Own lock on stcb at return from input o kern/141697 net [sctp] [panic] lock (sleep mutex) sctp-tcb not locked o kern/141696 net [rum] [panic] rum(4)+ vimage = kernel panic o kern/141695 net [sctp] [panic] kernel page fault with non-sleepable lo o kern/141646 net [em] em(4) + lagg(4) + vlan(4) generates ISL-tagged fr o kern/141314 net Network Performance has decreased by 30% [regression] o kern/141285 net [em] hangs down/up intel nic during creating vlan o kern/141023 net [carp] CARP arp replays with wrong src mac o kern/140970 net [bce] The two NetXtreme II BCM5709S NICs on our HP Bl4 o kern/140796 net [ath] [panic] privileged instruction fault o kern/140778 net [em] randomly panic in vlan/em o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140728 net [em] [patch] Fast irq registration in em driver o kern/140684 net [bce] Broadcom NetXtreme II BCM5709 1000Base-T - fail o kern/140647 net [em] [patch] e1000 driver does not correctly handle mu o kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc s kern/140597 net [request] implement Lost Retransmission Detection o kern/140567 net [ath] [patch] ath is not worked on my notebook PC o kern/140564 net [wpi] Problem with Intel(R) PRO/Wireless 3945ABG o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140326 net [em] em0: watchdog timeout when communicating to windo o kern/140245 net [ath] [panic] Kernel panic during network activity on o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/140051 net [bce] [arp] ARP not sent through Bridge Firewall with o kern/139761 net [bce] bce driver on IBM HS22 [No PHY found on Child MI o kern/139565 net [ipfilter] ipfilter ioctl SIOCDELST broken o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL o kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139162 net [fwip] [panic] 8.0-RC1 panics if using IP over firewir o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/139079 net [wpi] Failure to attach wpi(4) o kern/139058 net [ipfilter] mbuf cluster leak on FreeBSD 7.2 o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 o kern/138739 net [wpi] wpi(4) does not work very well under 8.0-BETA4 o kern/138694 net [bge] FreeBSD 6.3 release does not recognize Broadcom o amd64/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop f kern/138666 net [multicast] [panic] not working multicast through igmp o kern/138660 net [igb] igb driver troubles in 8.0-BETA4 o kern/138652 net [tcp] TCP window scaling value calculated incorrectly? o kern/138620 net [lagg] [patch] lagg port bpf-writes blocked o kern/138427 net [wpi] [panic] Kernel panic after trying set monitor wl o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR on 8.0-BE o kern/138266 net [panic] kernel panic when udp benchmark test used as r o kern/138177 net [ipfilter] FreeBSD crashing repeatedly in ip_nat.c:257 o kern/138046 net [tcp] tcp sockets stay in SYN_SENT even after receivin o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 o bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137795 net [sctp] [panic] mtx_lock() of destroyed mutex o kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o kern/137775 net [netgraph] [patch] Add XMIT_FAILOVER to ng_one2many o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137592 net [ath] panic - 7-STABLE (Aug 7, 2009 UTC) crashes on ne o bin/137484 net [patch] Integer overflow in wpa_supplicant(8) base64 e o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137317 net [tcp] logs full of syncache problems o kern/137279 net [bge] [panic] Page fault (fatal trap 12) NFS server w/ o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136943 net [wpi] [lor] wpi0_com_lock / wpi0 o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136876 net [bge] bge will not resume properly after suspend o kern/136836 net [ath] atheros card stops functioning after about 12 ho o bin/136661 net [patch] ndp(8) ignores -f option o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/136482 net [age] Attansic L1 Gigabit Ethernet recieves multicasts o kern/136426 net [panic] spawning several dhclients in parallel panics o kern/136168 net [em] em driver initialization fails on Intel 5000PSL m o kern/135836 net [bce] bce BCM5709 Watchdog after warm boot - ok after o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/135222 net [igb] low speed routing between two igb interfaces o kern/134956 net [em] FreeBSD 7.1 & 7.2, Intel PRO/1000 PT Quad Port Se o kern/134931 net [route] [fib] Route messages sent to all socket listen o kern/134658 net [bce] bce driver fails on PowerEdge m610 blade. o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134401 net [msk] [panic] Kernel Fatal trap 12: page fault while i o kern/134168 net [ral] ral driver problem on RT2525 2.4GHz transceiver o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/134079 net [em] "em0: Invalid MAC address" in FreeBSD-Current ( 8 o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133902 net [tun] Killing tun0 iface ssh tunnel causes Panic Strin o kern/133786 net [netinet] [patch] ip_input might cause kernel panic o kern/133736 net [udp] ip_id not protected ... o kern/133613 net [wpi] [panic] kernel panic in wpi(4) o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133328 net [bge] [panic] Kernel panics with Windows7 client o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre o kern/133218 net [carp] [hang] use of carp(4) causes system to freeze f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133204 net [msk] msk driver timeouts o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132991 net [bge] if_bge low performance problem f bin/132911 net ip6fw(8): argument type of fill_icmptypes is wrong and o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o kern/132885 net [wlan] 802.1x broken after SVN rev 189592 o conf/132851 net [fib] [patch] allow to setup fib for service running f o kern/132832 net [netinet] [patch] tcp_output() might generate invalid o bin/132798 net [patch] ggatec(8): ggated/ggatec connection slowdown p o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132722 net [ath] Wifi ath0 associates fine with AP, but DHCP or I o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132669 net [xl] 3c905-TX send DUP! in reply on ping (sometime) o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132285 net [carp] alias gives incorrect hash in dmesg o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/132107 net [carp] carp(4) advskew setting ignored when carp IP us o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o kern/131549 net ifconfig(8) can't clear 'monitor' mode on the wireless o kern/131536 net [netinet] [patch] kernel does allow manipulation of su o bin/131365 net route(8): route add changes interpretation of network o kern/131162 net [ath] Atheros driver bugginess and kernel crashes o kern/131153 net [iwi] iwi doesn't see a wireless network f kern/131087 net [ipw] [panic] ipw / iwi - no sent/received packets; iw f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour o kern/129750 net [ath] Atheros AR5006 exits on "cannot map register spa f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow o kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129352 net [xl] [patch] xl0 watchdog timeout o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o bin/128954 net ifconfig(8) deletes valid routes o kern/128917 net [wpi] [panic] if_wpi and wpa+tkip causing kernel panic o kern/128884 net [msk] if_msk page fault while in kernel mode o kern/128840 net [igb] page fault under load with igb/LRO o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o conf/128334 net [request] use wpa_cli in the "WPA DHCP" situation o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127928 net [tcp] [patch] TCP bandwidth gets squeezed every time t o kern/127834 net [ixgbe] [patch] wrong error counting o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) s kern/127587 net [bge] [request] if_bge(4) doesn't support BCM576X fami f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/127102 net [wpi] Intel 3945ABG low throughput o kern/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o bin/126822 net wpa_supplicant(8): WPA PSK does not work in adhoc mode o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126688 net [ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124127 net [msk] watchdog timeout (missed Tx interrupts) -- recov o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o bin/123633 net ifconfig(8) doesn't set inet and ether address in one f kern/123617 net [tcp] breaking connection when client downloading file o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) f kern/123172 net [bce] Watchdog timeout problems with if_bce o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122928 net [em] interface watchdog timeouts and stops receiving p f kern/122839 net [if_em] FreeBSD 7 multicast routing problem f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix o kern/122743 net [mbuf] [panic] vm_page_unwire: invalid wire count: 0 o kern/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122195 net [ed] Alignment problems in if_ed o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup [reg o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] [security] ppp(8): fix local stack overflow in o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/120966 net [rum] kernel panic with if_rum and WPA encryption p docs/120945 net [patch] ip6(4) man page lacks documentation for TCLASS o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o sparc/118932 net [panic] 7.0-BETA4/sparc-64 kernel panic in rip_output a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o kern/118727 net [netgraph] [patch] [request] add new ng_pf module a kern/118238 net [bce] [patch] bce driver shows "no carrier" on Intel S s kern/117717 net [panic] Kernel panic with Bittorrent client. o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113895 net [xl] xl0 fails on 6.2-RELEASE but worked fine on 5.5-R o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112570 net [bge] packet loss with bge driver on BCM5704 chipset o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111457 net [ral] ral(4) freeze o kern/110140 net [ipw] ipw fails under load o kern/109733 net [bge] bge link state issues [regression] o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o kern/109251 net [re] [patch] if_re cardbus card won't attach o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/108542 net [bce] Huge network latencies with 6.2-RELEASE / STABLE o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o kern/107850 net [bce] bce driver link negotiation is faulty o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/106243 net [nve] double fault panic in if_nve.c on high loads o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/105348 net [ath] ath device stopps TX o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/104485 net [bge] Broadcom BCM5704C: Intermittent on newer chip ve o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working f bin/97392 net ppp(8) hangs instead terminating o kern/97306 net [netgraph] NG_L2TP locks after connection with failed f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/96030 net [bfe] [patch] Install hangs with Broadcomm 440x NIC in o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear s kern/94863 net [bge] [patch] hack to get bge(4) working on IBM e326m o kern/94162 net [bge] 6.x kenel stale with bge(4) o kern/93886 net [ath] Atheros/D-Link DWL-G650 long delay to associate f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi f kern/92552 net A serious bug in most network drivers from 5.X to 6.X s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/92090 net [bge] bge0: watchdog timeout -- resetting o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/90890 net [vr] Problems with network: vr0: tx shutdown timeout s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if f kern/88082 net [ath] [panic] cts protection for ath0 causes panic o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87506 net [vr] [patch] Fix alias support on vr interfaces s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86871 net [tcp] [patch] allocation logic for PCBs in TIME_WAIT s o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ o kern/85266 net [xe] [patch] xe(4) driver does not recognise Xircom XE o kern/84202 net [ed] [patch] Holtek HT80232 PCI NIC recognition on Fre o bin/82975 net route change does not parse classfull network as given o bin/82185 net [patch] ndp(8) can delete the incorrect entry s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/80853 net [ed] [patch] add support for Compex RL2000/ISA in PnP o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph f kern/79262 net [dc] Adaptec ANA-6922 not fully supported o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if p kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/77341 net [ip6] problems with IPV6 implementation o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time f kern/73538 net [bge] problem with the Broadcom BCM5788 Gigabit Ethern o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/64556 net [sis] [patch] if_sis short cable fix problems with Net s kern/60293 net [patch] FreeBSD arp poison patch o kern/54383 net [nfs] [patch] NFS root configurations without dynamic f i386/45773 net [bge] Softboot causes autoconf failure on Broadcom 570 s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [arp] [patch] for static ARP tables in rc.network 386 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Jan 25 12:24:50 2010 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 0B2B0106568F; Mon, 25 Jan 2010 12:24:50 +0000 (UTC) (envelope-from rpaulo@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D5DCB8FC15; Mon, 25 Jan 2010 12:24:49 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o0PCOnS6012577; Mon, 25 Jan 2010 12:24:49 GMT (envelope-from rpaulo@freefall.freebsd.org) Received: (from rpaulo@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o0PCOnrt012573; Mon, 25 Jan 2010 12:24:49 GMT (envelope-from rpaulo) Date: Mon, 25 Jan 2010 12:24:49 GMT Message-Id: <201001251224.o0PCOnrt012573@freefall.freebsd.org> To: egorenar@gmail.com, rpaulo@FreeBSD.org, freebsd-net@FreeBSD.org From: rpaulo@FreeBSD.org Cc: Subject: Re: kern/143163: [ieee80211] [patch] Radiotap bug in ieee80211_sta.c:sta_input 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, 25 Jan 2010 12:24:50 -0000 Synopsis: [ieee80211] [patch] Radiotap bug in ieee80211_sta.c:sta_input State-Changed-From-To: open->closed State-Changed-By: rpaulo State-Changed-When: Mon Jan 25 12:24:24 UTC 2010 State-Changed-Why: I've fixed this on HEAD. Thanks! http://www.freebsd.org/cgi/query-pr.cgi?pr=143163 From owner-freebsd-net@FreeBSD.ORG Mon Jan 25 12:30:08 2010 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 E581D106568D for ; Mon, 25 Jan 2010 12:30:08 +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 D422F8FC1E for ; Mon, 25 Jan 2010 12:30:08 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o0PCU8OI012801 for ; Mon, 25 Jan 2010 12:30:08 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o0PCU8wj012796; Mon, 25 Jan 2010 12:30:08 GMT (envelope-from gnats) Date: Mon, 25 Jan 2010 12:30:08 GMT Message-Id: <201001251230.o0PCU8wj012796@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/143163: 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: Mon, 25 Jan 2010 12:30:09 -0000 The following reply was made to PR kern/143163; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/143163: commit references a PR Date: Mon, 25 Jan 2010 12:24:02 +0000 (UTC) Author: rpaulo Date: Mon Jan 25 12:23:51 2010 New Revision: 202967 URL: http://svn.freebsd.org/changeset/base/202967 Log: Call ieee80211_radiotap_rx, not ieee80211_radiotap_tx on sta_input() PR: 143163 Submitted by: Alexander Egorenkov MFC after: 3 days Modified: head/sys/net80211/ieee80211_sta.c Modified: head/sys/net80211/ieee80211_sta.c ============================================================================== --- head/sys/net80211/ieee80211_sta.c Mon Jan 25 12:05:51 2010 (r202966) +++ head/sys/net80211/ieee80211_sta.c Mon Jan 25 12:23:51 2010 (r202967) @@ -759,7 +759,7 @@ sta_input(struct ieee80211_node *ni, str /* copy to listener after decrypt */ if (ieee80211_radiotap_active_vap(vap)) - ieee80211_radiotap_tx(vap, m); + ieee80211_radiotap_rx(vap, m); need_tap = 0; /* _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Mon Jan 25 13:05:25 2010 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 0494A1065692 for ; Mon, 25 Jan 2010 13:05:25 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 4D08D8FC12 for ; Mon, 25 Jan 2010 13:05:23 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA16399; Mon, 25 Jan 2010 14:47:03 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4B5D92C7.8070908@icyb.net.ua> Date: Mon, 25 Jan 2010 14:47:03 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20091206) MIME-Version: 1.0 To: freebsd-net@freebsd.org, freebsd-current@freebsd.org X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Subject: tun setup (routing?) issue in head 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, 25 Jan 2010 13:05:25 -0000 I've updated my HEAD amd64 system from December's sources to something more recent and I've got problems with security/vpnc. To be precise vpnc itself seems to work as good as before but its post-connect script is now failing: $ ifconfig tun0 inet 10.99.15.144 10.99.15.144 netmask 255.255.255.255 mtu 1412 up ifconfig: ioctl (SIOCAIFADDR): File exists Where tun0 is an interface created by vpnc. ktrace gives this: ifconfig CALL socket(PF_INET,SOCK_DGRAM,IPPROTO_IP) ifconfig RET socket 3 ifconfig CALL ioctl(0x3,SIOCSIFMTU,0x525a60) ifconfig RET ioctl 0 ifconfig CALL ioctl(0x3,SIOCGIFFLAGS,0x7fffffffda30) ifconfig RET ioctl 0 ifconfig CALL ioctl(0x3,SIOCSIFFLAGS,0x7fffffffda30) ifconfig RET ioctl 0 ifconfig CALL ioctl(0x3,SIOCDIFADDR,0x525380) ifconfig RET ioctl -1 errno 49 Can't assign requested address ifconfig CALL ioctl(0x3,SIOCAIFADDR,0x525340) ifconfig RET ioctl -1 errno 17 File exists ifconfig CALL write(0x2,0x7fffffffd2d0,0xa) So, what's happening? Do you I have to update the ifconfig command? Or is there some issue in the networking code? BTW, I also get the following messages in the system log when vpnc is started: kernel: tun0: link state changed to UP kernel: ifa_add_loopback_route: insertion failed I have net.link.tap.up_on_open=1 in sysctl.conf if that matters. -- Andriy Gapon From owner-freebsd-net@FreeBSD.ORG Mon Jan 25 15:54:56 2010 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 0C4451065676; Mon, 25 Jan 2010 15:54:56 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id D0C1C8FC19; Mon, 25 Jan 2010 15:54:55 +0000 (UTC) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id o0PFssqd012115; Mon, 25 Jan 2010 07:54:55 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Jan 2010 07:52:56 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: tun setup (routing?) issue in head Thread-Index: AcqdvJcHBYXgJd9IRSK9UrbZhv7sPQAGd89+ References: <4B5D92C7.8070908@icyb.net.ua> From: "Li, Qing" To: "Andriy Gapon" , , Cc: Subject: RE: tun setup (routing?) issue in head 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, 25 Jan 2010 15:54:56 -0000 Yes, the failure is due to route installation. To make a long story = short, many of the scripts that worked before not necessary because of the right reasons.=20 =20 I have been very busy at work, but I do have a patch and I will try to = get it=20 finalized shortly. =20 -- Qing =20 ________________________________ From: owner-freebsd-current@freebsd.org on behalf of Andriy Gapon Sent: Mon 1/25/2010 4:47 AM To: freebsd-net@freebsd.org; freebsd-current@freebsd.org Subject: tun setup (routing?) issue in head I've updated my HEAD amd64 system from December's sources to something = more recent and I've got problems with security/vpnc. To be precise vpnc itself = seems to work as good as before but its post-connect script is now failing: $ ifconfig tun0 inet 10.99.15.144 10.99.15.144 netmask 255.255.255.255 = mtu 1412 up ifconfig: ioctl (SIOCAIFADDR): File exists Where tun0 is an interface created by vpnc. ktrace gives this: ifconfig CALL socket(PF_INET,SOCK_DGRAM,IPPROTO_IP) ifconfig RET socket 3 ifconfig CALL ioctl(0x3,SIOCSIFMTU,0x525a60) ifconfig RET ioctl 0 ifconfig CALL ioctl(0x3,SIOCGIFFLAGS,0x7fffffffda30) ifconfig RET ioctl 0 ifconfig CALL ioctl(0x3,SIOCSIFFLAGS,0x7fffffffda30) ifconfig RET ioctl 0 ifconfig CALL ioctl(0x3,SIOCDIFADDR,0x525380) ifconfig RET ioctl -1 errno 49 Can't assign requested address ifconfig CALL ioctl(0x3,SIOCAIFADDR,0x525340) ifconfig RET ioctl -1 errno 17 File exists ifconfig CALL write(0x2,0x7fffffffd2d0,0xa) So, what's happening? Do you I have to update the ifconfig command? Or is there some issue in the networking code? BTW, I also get the following messages in the system log when vpnc is = started: kernel: tun0: link state changed to UP kernel: ifa_add_loopback_route: insertion failed I have net.link.tap.up_on_open=3D1 in sysctl.conf if that matters. -- Andriy Gapon _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Mon Jan 25 16:02:07 2010 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 3BEB7106566C; Mon, 25 Jan 2010 16:02:07 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 4BBC78FC12; Mon, 25 Jan 2010 16:02:05 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA19719; Mon, 25 Jan 2010 18:01:08 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4B5DC043.7030806@icyb.net.ua> Date: Mon, 25 Jan 2010 18:01:07 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20091206) MIME-Version: 1.0 To: "Li, Qing" References: <4B5D92C7.8070908@icyb.net.ua> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: tun setup (routing?) issue in head 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, 25 Jan 2010 16:02:07 -0000 on 25/01/2010 17:52 Li, Qing said the following: > Yes, the failure is due to route installation. To make a long story short, many of the > scripts that worked before not necessary because of the right reasons. > > I have been very busy at work, but I do have a patch and I will try to get it > finalized shortly. I see, cool! Perhaps there is some interim work-around for this issue? I can not access my work VPN because of this and I don't like having to roll back my kernel. > From: owner-freebsd-current@freebsd.org on behalf of Andriy Gapon > Sent: Mon 1/25/2010 4:47 AM > To: freebsd-net@freebsd.org; freebsd-current@freebsd.org > Subject: tun setup (routing?) issue in head > > > > > I've updated my HEAD amd64 system from December's sources to something more recent > and I've got problems with security/vpnc. To be precise vpnc itself seems to work > as good as before but its post-connect script is now failing: > > $ ifconfig tun0 inet 10.99.15.144 10.99.15.144 netmask 255.255.255.255 mtu 1412 up > ifconfig: ioctl (SIOCAIFADDR): File exists > > Where tun0 is an interface created by vpnc. > ktrace gives this: > ifconfig CALL socket(PF_INET,SOCK_DGRAM,IPPROTO_IP) > ifconfig RET socket 3 > ifconfig CALL ioctl(0x3,SIOCSIFMTU,0x525a60) > ifconfig RET ioctl 0 > ifconfig CALL ioctl(0x3,SIOCGIFFLAGS,0x7fffffffda30) > ifconfig RET ioctl 0 > ifconfig CALL ioctl(0x3,SIOCSIFFLAGS,0x7fffffffda30) > ifconfig RET ioctl 0 > ifconfig CALL ioctl(0x3,SIOCDIFADDR,0x525380) > ifconfig RET ioctl -1 errno 49 Can't assign requested address > ifconfig CALL ioctl(0x3,SIOCAIFADDR,0x525340) > ifconfig RET ioctl -1 errno 17 File exists > ifconfig CALL write(0x2,0x7fffffffd2d0,0xa) > > So, what's happening? > Do you I have to update the ifconfig command? > Or is there some issue in the networking code? > > BTW, I also get the following messages in the system log when vpnc is started: > kernel: tun0: link state changed to UP > kernel: ifa_add_loopback_route: insertion failed > I have net.link.tap.up_on_open=1 in sysctl.conf if that matters. > > -- > Andriy Gapon > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > -- Andriy Gapon From owner-freebsd-net@FreeBSD.ORG Mon Jan 25 16:37:41 2010 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 A035F1065676; Mon, 25 Jan 2010 16:37:41 +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 784558FC20; Mon, 25 Jan 2010 16:37:41 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o0PGbf3e028533; Mon, 25 Jan 2010 16:37:41 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o0PGbfjR028529; Mon, 25 Jan 2010 16:37:41 GMT (envelope-from linimon) Date: Mon, 25 Jan 2010 16:37:41 GMT Message-Id: <201001251637.o0PGbfjR028529@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/143208: [ipsec] [gif] IPSec over gif interface not working 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, 25 Jan 2010 16:37:41 -0000 Old Synopsis: IPSec over gif interface New Synopsis: [ipsec] [gif] IPSec over gif interface not working Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Jan 25 16:36:05 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). Note: potential duplicate of kern/122065 and kern/121642. http://www.freebsd.org/cgi/query-pr.cgi?pr=143208 From owner-freebsd-net@FreeBSD.ORG Mon Jan 25 16:46:01 2010 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 E7C381065676; Mon, 25 Jan 2010 16:46:01 +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 BF8D48FC22; Mon, 25 Jan 2010 16:46:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o0PGk1m6036773; Mon, 25 Jan 2010 16:46:01 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o0PGk1GL036769; Mon, 25 Jan 2010 16:46:01 GMT (envelope-from linimon) Date: Mon, 25 Jan 2010 16:46:01 GMT Message-Id: <201001251646.o0PGk1GL036769@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-amd64@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/143213: [rum] EDIMAX EW-7318USg can't set IP adress 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, 25 Jan 2010 16:46:02 -0000 Old Synopsis: EDIMAX EW-7318USg can't set IP adress New Synopsis: [rum] EDIMAX EW-7318USg can't set IP adress Responsible-Changed-From-To: freebsd-amd64->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Jan 25 16:44:59 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=143213 From owner-freebsd-net@FreeBSD.ORG Mon Jan 25 18:57:18 2010 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 31EB11065679 for ; Mon, 25 Jan 2010 18:57:18 +0000 (UTC) (envelope-from piokud84@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id BC4478FC0A for ; Mon, 25 Jan 2010 18:57:17 +0000 (UTC) Received: by fxm27 with SMTP id 27so1120181fxm.3 for ; Mon, 25 Jan 2010 10:57:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=f9rbzv+Ka1afXqinSOoB1CN8nI97YQAvXnQb+2MzL38=; b=YtB08D0DTJD22L7DpGa5bze+H7RH6+tHijoMlyHwHQE0Xegf5nJL2u5Ofc6ReP3iZk nSBNHpvihojZ7BlrN6zaOYxXjk3p+OLmnV4BvB+BXRf1XLzlR/SEOPx8ixatwJXT9Vv9 vjnw1N2O/qqAYeKnf5yfpH9+Y5ZuQs+ZIjtOg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=mxM8O9AU12dZ3kUTF9SZYXQJTSed+rDjZ1K/VbK9wmT9jRfI+11ZKWFbhDuGlhGWzL lGpkbjL3OcCzur/NUeV/mqzq6EAv1YS/dGAKE3Le9nmAaCyd4hep9k0Qf/oAcktBQ/2P i7Vt5JSl7JWbqzbjpYzPDjqBrvuoQxAcv5G08= Received: by 10.223.14.20 with SMTP id e20mr7311812faa.16.1264444498216; Mon, 25 Jan 2010 10:34:58 -0800 (PST) Received: from ?192.168.0.6? (chello089074015015.chello.pl [89.74.15.15]) by mx.google.com with ESMTPS id 16sm2885962fxm.8.2010.01.25.10.34.57 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 25 Jan 2010 10:34:57 -0800 (PST) Message-ID: <4B5DD63C.9090608@gmail.com> Date: Mon, 25 Jan 2010 18:34:52 +0100 From: Piotrek User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: freebsd-net@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: 143213 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, 25 Jan 2010 18:57:18 -0000 Sorry, my bad, didn't ceate wlan0 device evething works fine Regards Piotr From owner-freebsd-net@FreeBSD.ORG Mon Jan 25 19:06:45 2010 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 182F21065697; Mon, 25 Jan 2010 19:06:45 +0000 (UTC) (envelope-from delphij@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E434E8FC27; Mon, 25 Jan 2010 19:06:44 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o0PJ6ios055792; Mon, 25 Jan 2010 19:06:44 GMT (envelope-from delphij@freefall.freebsd.org) Received: (from delphij@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o0PJ6ifa055788; Mon, 25 Jan 2010 19:06:44 GMT (envelope-from delphij) Date: Mon, 25 Jan 2010 19:06:44 GMT Message-Id: <201001251906.o0PJ6ifa055788@freefall.freebsd.org> To: piokud84@gmail.com, delphij@FreeBSD.org, freebsd-net@FreeBSD.org, delphij@FreeBSD.org From: delphij@FreeBSD.org Cc: Subject: Re: kern/143213: [rum] EDIMAX EW-7318USg can't set IP adress 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, 25 Jan 2010 19:06:45 -0000 Synopsis: [rum] EDIMAX EW-7318USg can't set IP adress State-Changed-From-To: open->closed State-Changed-By: delphij State-Changed-When: Mon Jan 25 19:05:34 UTC 2010 State-Changed-Why: Submitter notes that this was actually caused by not creating the wlan0 device so it's not a bug. Responsible-Changed-From-To: freebsd-net->delphij Responsible-Changed-By: delphij Responsible-Changed-When: Mon Jan 25 19:05:34 UTC 2010 Responsible-Changed-Why: Take just in case I was wrong. http://www.freebsd.org/cgi/query-pr.cgi?pr=143213 From owner-freebsd-net@FreeBSD.ORG Mon Jan 25 22:10:50 2010 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 AC386106566C; Mon, 25 Jan 2010 22:10:50 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [IPv6:2001:470:a803::1]) by mx1.freebsd.org (Postfix) with ESMTP id B27AE8FC18; Mon, 25 Jan 2010 22:10:48 +0000 (UTC) Received: from mail.geekcn.org (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 927C3A57A6C; Tue, 26 Jan 2010 06:10:47 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by mail.geekcn.org (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with LMTP id gHSKyhUBleUe; Tue, 26 Jan 2010 06:10:40 +0800 (CST) Received: from delta.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 8C52FA57A21; Tue, 26 Jan 2010 06:10:38 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:x-enigmail-version:openpgp:content-type; b=Ii+5YEmfqUja/3ullKNdx72RKb5g01FU8u6kYf5LU0c3lBNibGs3hz7UNUVeVl7Fx P5sU7uQKPXA2hxOCopHzQ== Message-ID: <4B5E16DB.2080203@delphij.net> Date: Mon, 25 Jan 2010 14:10:35 -0800 From: Xin LI Organization: The Geek China Organization User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.7) Gecko/20100122 Thunderbird/3.0.1 ThunderBrowse/3.2.8.1 MIME-Version: 1.0 To: freebsd-net@freebsd.org X-Enigmail-Version: 1.0 OpenPGP: id=3FCA37C1; url=http://www.delphij.net/delphij.asc Content-Type: multipart/mixed; boundary="------------090205010302020105020607" Cc: delphij@freebsd.org, Robert Watson , jhb@freebsd.org Subject: [PATCH] Interface description X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 22:10:50 -0000 This is a multi-part message in MIME format. --------------090205010302020105020607 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I have revised the patchset based on feedback received. This version: - Unbreak the case when libpcap is being built for pre-ifdescr world. - Documents the descr and -descr primitives for ifconfig(8), they are intended for OpenBSD compatibility. - Simplify and concentrate memory allocation in ifconfig(8) - Document the use of nul terminated buffer and the meaning of length parameter - Use char* instead of sbuf and simplify the logic in kernel part. Hopefully this version would address all problems raised by reviewers. Comments? Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iQEcBAEBAgAGBQJLXhbbAAoJEATO+BI/yjfBWg8IAJTruuq7gMcB3SS/CP7hhRPN 2lN7N3NxTz9V1s4mkzZ4/EFtM+mpwn30PYlZ7Q4t9QdPgnUbH54hQt+FJU1EHSnd U+CyilDA7kR7AlnAv9Rk7RxjF/zq19JiVIbZn3DZFQI20EpfFap/PzbdGWNZiGtz Lp7Q7v7/FgIk5dwNtjbXnyd9sOAc67oBi33rd6KOORKZLtzDz3xZYuTaasT1ZGfp LtCWRHKeMcFR0lHr3meEYxzkj8C48UIoTvp486vgak2hcE1ez7fgCJb+lvEbIxxs x5h5g+330z5XG0vHJLFyNQEs8oMTh5KihqcOD0/nBONYryXJnOmvskm3c64zJko= =mElq -----END PGP SIGNATURE----- --------------090205010302020105020607 Content-Type: text/plain; name="ifdescr.diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ifdescr.diff" SW5kZXg6IGNvbnRyaWIvbGlicGNhcC9pbmV0LmMKPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gY29udHJp Yi9saWJwY2FwL2luZXQuYwkocmV2aXNpb24gMjAyOTc5KQorKysgY29udHJpYi9saWJwY2Fw L2luZXQuYwkod29ya2luZyBjb3B5KQpAQCAtNDAxLDExICs0MDEsMTYgQEAgYWRkX2FkZHJf dG9faWZsaXN0KHBjYXBfaWZfdCAqKmFsbGRldnMsIGNvbnN0IGNoYXIKIAlwY2FwX2lmX3Qg KmN1cmRldjsKIAljaGFyICpkZXNjcmlwdGlvbiA9IE5VTEw7CiAJcGNhcF9hZGRyX3QgKmN1 cmFkZHIsICpwcmV2YWRkciwgKm5leHRhZGRyOworCWludCBzOwogI2lmZGVmIFNJT0NHSUZE RVNDUgogCXN0cnVjdCBpZnJlcSBpZnJkZXNjOworI2lmbmRlZiBJRkRFU0NSU0laRQorI2Rl ZmluZSBfSUZERVNDUlNJWkUgNjQKKwljaGFyIGlmZGVzY3JbX0lGREVTQ1JTSVpFXTsKKyNl bHNlCiAJY2hhciBpZmRlc2NyW0lGREVTQ1JTSVpFXTsKLQlpbnQgczsKICNlbmRpZgorI2Vu ZGlmCiAKICNpZmRlZiBTSU9DR0lGREVTQ1IKIAkvKgpAQCAtNDEzLDEyICs0MTgsMTcgQEAg YWRkX2FkZHJfdG9faWZsaXN0KHBjYXBfaWZfdCAqKmFsbGRldnMsIGNvbnN0IGNoYXIKIAkg Ki8KIAltZW1zZXQoJmlmcmRlc2MsIDAsIHNpemVvZiBpZnJkZXNjKTsKIAlzdHJsY3B5KGlm cmRlc2MuaWZyX25hbWUsIG5hbWUsIHNpemVvZiBpZnJkZXNjLmlmcl9uYW1lKTsKKyNpZmRl ZiBfX0ZyZWVCU0RfXworCWlmcmRlc2MuaWZyX2J1ZmZlci5idWZmZXIgPSBpZmRlc2NyOwor CWlmcmRlc2MuaWZyX2J1ZmZlci5sZW5ndGggPSBzaXplb2YoaWZkZXNjcik7CisjZWxzZQog CWlmcmRlc2MuaWZyX2RhdGEgPSAoY2FkZHJfdCkmaWZkZXNjcjsKKyNlbmRpZgogCXMgPSBz b2NrZXQoQUZfSU5FVCwgU09DS19ER1JBTSwgMCk7CiAJaWYgKHMgPj0gMCkgewogCQlpZiAo aW9jdGwocywgU0lPQ0dJRkRFU0NSLCAmaWZyZGVzYykgPT0gMCAmJgotCQkgICAgc3RybGVu KGlmcmRlc2MuaWZyX2RhdGEpICE9IDApCi0JCQlkZXNjcmlwdGlvbiA9IGlmcmRlc2MuaWZy X2RhdGE7CisJCSAgICBzdHJsZW4oaWZkZXNjcikgIT0gMCkKKwkJCWRlc2NyaXB0aW9uID0g aWZkZXNjcjsKIAkJY2xvc2Uocyk7CiAJfQogI2VuZGlmCkluZGV4OiBzYmluL2lmY29uZmln L2lmY29uZmlnLjgKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc2Jpbi9pZmNvbmZpZy9pZmNvbmZpZy44 CShyZXZpc2lvbiAyMDI5NzkpCisrKyBzYmluL2lmY29uZmlnL2lmY29uZmlnLjgJKHdvcmtp bmcgY29weSkKQEAgLTI4LDcgKzI4LDcgQEAKIC5cIiAgICAgRnJvbTogQCgjKWlmY29uZmln LjgJOC4zIChCZXJrZWxleSkgMS81Lzk0CiAuXCIgJEZyZWVCU0QkCiAuXCIKLS5EZCBTZXB0 ZW1iZXIgMjMsIDIwMDkKKy5EZCBKYW51YXJ5IDI1LCAyMDEwCiAuRHQgSUZDT05GSUcgOAog Lk9zCiAuU2ggTkFNRQpAQCAtMjU4LDYgKzI1OCwxMiBAQCBEaXNhYmxlIHBlcm1hbmVudGx5 IHByb21pc2N1b3VzIG1vZGUuCiBBbm90aGVyIG5hbWUgZm9yIHRoZQogLkZsIGFsaWFzCiBw YXJhbWV0ZXIuCisuSXQgQ20gZGVzY3JpcHRpb24gQXIgdmFsdWUgLCBDbSBkZXNjciBBciB2 YWx1ZQorU3BlY2lmeSBhIGRlc2NyaXB0aW9uIG9mIHRoZSBpbnRlcmZhY2UuCitUaGlzIGNh biBiZSB1c2VkIHRvIGxhYmVsIGludGVyZmFjZXMgaW4gc2l0dWF0aW9ucyB3aGVyZSB0aGV5 IG1heQorb3RoZXJ3aXNlIGJlIGRpZmZpY3VsdCB0byBkaXN0aW5ndWlzaC4KKy5JdCBDbSAt ZGVzY3JpcHRpb24gLCBDbSAtZGVzY3IKK0NsZWFyIHRoZSBpbnRlcmZhY2UgZGVzY3JpcHRp b24uCiAuSXQgQ20gZG93bgogTWFyayBhbiBpbnRlcmZhY2UKIC5EcSBkb3duIC4KQEAgLTI1 MTIsNiArMjUxOCwxMCBAQCBDb25maWd1cmUgdGhlIGludGVyZmFjZQogdG8gdXNlIDEwMGJh c2VUWCwgZnVsbCBkdXBsZXggRXRoZXJuZXQgbWVkaWEgb3B0aW9uczoKIC5EbCAjIGlmY29u ZmlnIHhsMCBtZWRpYSAxMDBiYXNlVFggbWVkaWFvcHQgZnVsbC1kdXBsZXgKIC5QcAorTGFi ZWwgdGhlIGVtMCBpbnRlcmZhY2UgYXMgYW4gdXBsaW5rOgorLlBwCisuRGwgIyBpZmNvbmZp ZyBlbTAgZGVzY3JpcHRpb24gXCYiVXBsaW5rIHRvIEdpZ2FiaXQgU3dpdGNoIDJcJiIKKy5Q cAogQ3JlYXRlIHRoZSBzb2Z0d2FyZSBuZXR3b3JrIGludGVyZmFjZQogLkxpIGdpZjEgOgog LkRsICMgaWZjb25maWcgZ2lmMSBjcmVhdGUKSW5kZXg6IHNiaW4vaWZjb25maWcvaWZjb25m aWcuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09Ci0tLSBzYmluL2lmY29uZmlnL2lmY29uZmlnLmMJKHJldmlz aW9uIDIwMjk3OSkKKysrIHNiaW4vaWZjb25maWcvaWZjb25maWcuYwkod29ya2luZyBjb3B5 KQpAQCAtNDQsNyArNDQsNiBAQCBzdGF0aWMgY29uc3QgY2hhciByY3NpZFtdID0KICNpbmNs dWRlIDxzeXMvcGFyYW0uaD4KICNpbmNsdWRlIDxzeXMvaW9jdGwuaD4KICNpbmNsdWRlIDxz eXMvc29ja2V0Lmg+Ci0jaW5jbHVkZSA8c3lzL3N5c2N0bC5oPgogI2luY2x1ZGUgPHN5cy90 aW1lLmg+CiAjaW5jbHVkZSA8c3lzL21vZHVsZS5oPgogI2luY2x1ZGUgPHN5cy9saW5rZXIu aD4KQEAgLTgzLDYgKzgyLDggQEAgc3RhdGljIGNvbnN0IGNoYXIgcmNzaWRbXSA9CiBzdHJ1 Y3QJaWZyZXEgaWZyOwogCiBjaGFyCW5hbWVbSUZOQU1TSVpdOworY2hhcgkqZGVzY3IgPSBO VUxMOworc2l6ZV90CWRlc2NybGVuID0gNjQ7CiBpbnQJc2V0YWRkcjsKIGludAlzZXRtYXNr OwogaW50CWRvYWxpYXM7CkBAIC04MzgsNiArODM5LDM1IEBAIHNldGlmbmFtZShjb25zdCBj aGFyICp2YWwsIGludCBkdW1teSBfX3VudXNlZCwgaW50CiAJZnJlZShuZXduYW1lKTsKIH0K IAorLyogQVJHU1VTRUQgKi8KK3N0YXRpYyB2b2lkCitzZXRpZmRlc2NyKGNvbnN0IGNoYXIg KnZhbCwgaW50IGR1bW15IF9fdW51c2VkLCBpbnQgcywgCisgICAgY29uc3Qgc3RydWN0IGFm c3d0Y2ggKmFmcCkKK3sKKwljaGFyICpuZXdkZXNjcjsKKworCW5ld2Rlc2NyID0gc3RyZHVw KHZhbCk7CisJaWYgKG5ld2Rlc2NyID09IE5VTEwpIHsKKwkJd2Fybigibm8gbWVtb3J5IHRv IHNldCBpZmRlc2NyIik7CisJCXJldHVybjsKKwl9CisKKwlpZnIuaWZyX2J1ZmZlci5idWZm ZXIgPSBuZXdkZXNjcjsKKwlpZnIuaWZyX2J1ZmZlci5sZW5ndGggPSBzdHJsZW4obmV3ZGVz Y3IpICsgMTsKKwlpZiAoaW9jdGwocywgU0lPQ1NJRkRFU0NSLCAoY2FkZHJfdCkmaWZyKSA8 IDApCisJCXdhcm4oImlvY3RsIChzZXQgZGVzY3IpIik7CisKKwlmcmVlKG5ld2Rlc2NyKTsK K30KKworLyogQVJHU1VTRUQgKi8KK3N0YXRpYyB2b2lkCit1bnNldGlmZGVzY3IoY29uc3Qg Y2hhciAqdmFsLCBpbnQgdmFsdWUsIGludCBzLCBjb25zdCBzdHJ1Y3QgYWZzd3RjaCAqYWZw KQoreworCisJc2V0aWZkZXNjcigiIiwgMCwgcywgMCk7Cit9CisKICNkZWZpbmUJSUZGQklU UyBcCiAiXDAyMFwxVVBcMkJST0FEQ0FTVFwzREVCVUdcNExPT1BCQUNLXDVQT0lOVE9QT0lO VFw2U01BUlRcN1JVTk5JTkciIFwKICJcMTBOT0FSUFwxMVBST01JU0NcMTJBTExNVUxUSVwx M09BQ1RJVkVcMTRTSU1QTEVYXDE1TElOSzBcMTZMSU5LMVwxN0xJTksyIiBcCkBAIC04ODIs NiArOTEyLDIyIEBAIHN0YXR1cyhjb25zdCBzdHJ1Y3QgYWZzd3RjaCAqYWZwLCBjb25zdCBz dHJ1Y3Qgc29jCiAJCXByaW50ZigiIG10dSAlZCIsIGlmci5pZnJfbXR1KTsKIAlwdXRjaGFy KCdcbicpOwogCisJZG8geworCQlpZiAoKGRlc2NyID0gcmVhbGxvY2YoZGVzY3IsIGRlc2Ny bGVuKSkgIT0gTlVMTCkgeworCQkJaWZyLmlmcl9idWZmZXIuYnVmZmVyID0gZGVzY3I7CisJ CQlpZnIuaWZyX2J1ZmZlci5sZW5ndGggPSBkZXNjcmxlbjsKKwkJCWlmIChpb2N0bChzLCBT SU9DR0lGREVTQ1IsICZpZnIpID09IDApIHsKKwkJCSAgICBpZiAoc3RybGVuKGRlc2NyKSA+ IDApCisJCQkJcHJpbnRmKCJcdGRlc2NyaXB0aW9uOiAlc1xuIiwgZGVzY3IpOworCQkJfSBl bHNlIGlmIChlcnJubyA9PSBFTkFNRVRPT0xPTkcpIHsKKwkJCQlkZXNjcmxlbiAqPSAyOwor CQkJCWNvbnRpbnVlOworCQkJfQorCQl9IGVsc2UKKwkJCXdhcm4oInVuYWJsZSB0byBhbGxv Y2F0ZSBtZW1vcnkgZm9yIGludGVyZmFjZSIKKwkJCSAgICAiZGVzY3JpcHRpb24iKTsKKwl9 IHdoaWxlICgwKTsKKwogCWlmIChpb2N0bChzLCBTSU9DR0lGQ0FQLCAoY2FkZHJfdCkmaWZy KSA9PSAwKSB7CiAJCWlmIChpZnIuaWZyX2N1cmNhcCAhPSAwKSB7CiAJCQlwcmludGIoIlx0 b3B0aW9ucyIsIGlmci5pZnJfY3VyY2FwLCBJRkNBUEJJVFMpOwpAQCAtMTA1MSw2ICsxMDk3 LDEwIEBAIHN0YXRpYyBzdHJ1Y3QgY21kIGJhc2ljX2NtZHNbXSA9IHsKIAlERUZfQ01EKCIt YXJwIiwJCUlGRl9OT0FSUCwJc2V0aWZmbGFncyksCiAJREVGX0NNRCgiZGVidWciLAlJRkZf REVCVUcsCXNldGlmZmxhZ3MpLAogCURFRl9DTUQoIi1kZWJ1ZyIsCS1JRkZfREVCVUcsCXNl dGlmZmxhZ3MpLAorCURFRl9DTURfQVJHKCJkZXNjcmlwdGlvbiIsCQlzZXRpZmRlc2NyKSwK KwlERUZfQ01EX0FSRygiZGVzY3IiLAkJCXNldGlmZGVzY3IpLAorCURFRl9DTUQoIi1kZXNj cmlwdGlvbiIsCTAsCQl1bnNldGlmZGVzY3IpLAorCURFRl9DTUQoIi1kZXNjciIsCTAsCQl1 bnNldGlmZGVzY3IpLAogCURFRl9DTUQoInByb21pc2MiLAlJRkZfUFBST01JU0MsCXNldGlm ZmxhZ3MpLAogCURFRl9DTUQoIi1wcm9taXNjIiwJLUlGRl9QUFJPTUlTQywJc2V0aWZmbGFn cyksCiAJREVGX0NNRCgiYWRkIiwJCUlGRl9VUCwJCW5vdGVhbGlhcyksCkluZGV4OiBzaGFy ZS9tYW4vbWFuNC9uZXRpbnRyby40Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHNoYXJlL21hbi9tYW40 L25ldGludHJvLjQJKHJldmlzaW9uIDIwMjk3OSkKKysrIHNoYXJlL21hbi9tYW40L25ldGlu dHJvLjQJKHdvcmtpbmcgY29weSkKQEAgLTMyLDcgKzMyLDcgQEAKIC5cIiAgICAgQCgjKW5l dGludHJvLjQJOC4yIChCZXJrZWxleSkgMTEvMzAvOTMKIC5cIiAkRnJlZUJTRCQKIC5cIgot LkRkIEp1bmUgMTgsIDIwMDQKKy5EZCBKYW51YXJ5IDI1LCAyMDEwCiAuRHQgTkVUSU5UUk8g NAogLk9zCiAuU2ggTkFNRQpAQCAtMjA0LDYgKzIwNCw3IEBAIHN0cnVjdAlpZnJlcSB7CiAg ICAgICAgIHN0cnVjdCAgICBzb2NrYWRkciBpZnJ1X2FkZHI7CiAgICAgICAgIHN0cnVjdCAg ICBzb2NrYWRkciBpZnJ1X2RzdGFkZHI7CiAgICAgICAgIHN0cnVjdCAgICBzb2NrYWRkciBp ZnJ1X2Jyb2FkYWRkcjsKKyAgICAgICAgc3RydWN0IHsgc2l6ZV90IGxlbmd0aDsgY2FkZHJf dCBidWZmZXI7IH0gaWZydV9idWZmZXI7CiAgICAgICAgIHNob3J0ICAgICBpZnJ1X2ZsYWdz WzJdOwogICAgICAgICBzaG9ydCAgICAgaWZydV9pbmRleDsKICAgICAgICAgaW50ICAgICAg IGlmcnVfbWV0cmljOwpAQCAtMjE2LDYgKzIxNyw3IEBAIHN0cnVjdAlpZnJlcSB7CiAjZGVm aW5lIGlmcl9hZGRyICAgICAgaWZyX2lmcnUuaWZydV9hZGRyICAgICAgLyogYWRkcmVzcyAq LwogI2RlZmluZSBpZnJfZHN0YWRkciAgIGlmcl9pZnJ1LmlmcnVfZHN0YWRkciAgIC8qIG90 aGVyIGVuZCBvZiBwLXRvLXAgbGluayAqLwogI2RlZmluZSBpZnJfYnJvYWRhZGRyIGlmcl9p ZnJ1LmlmcnVfYnJvYWRhZGRyIC8qIGJyb2FkY2FzdCBhZGRyZXNzICovCisjZGVmaW5lIGlm cl9idWZmZXIgICAgaWZyX2lmcnUuaWZydV9idWZmZXIgICAgLyogdXNlciBzdXBwbGllZCBi dWZmZXIgd2l0aCBpdHMgbGVuZ3RoICovCiAjZGVmaW5lIGlmcl9mbGFncyAgICAgaWZyX2lm cnUuaWZydV9mbGFnc1swXSAgLyogZmxhZ3MgKGxvdyAxNiBiaXRzKSAqLwogI2RlZmluZSBp ZnJfZmxhZ3NoaWdoIGlmcl9pZnJ1LmlmcnVfZmxhZ3NbMV0gIC8qIGZsYWdzIChoaWdoIDE2 IGJpdHMpICovCiAjZGVmaW5lIGlmcl9tZXRyaWMgICAgaWZyX2lmcnUuaWZydV9tZXRyaWMg ICAgLyogbWV0cmljICovCkBAIC0yNzcsNiArMjc5LDI2IEBAIGFuZAogZmllbGRzIG9mIHRo ZQogLlZ0IGlmcmVxCiBzdHJ1Y3R1cmUsIHJlc3BlY3RpdmVseS4KKy5JdCBEdiBTSU9DR0lG REVTQ1IKK0dldCB0aGUgaW50ZXJmYWNlIGRlc2NyaXB0aW9uLCByZXR1cm5lZCBpbiB0aGUK Ky5WYSBidWZmZXIKK2ZpZWxkIG9mCisuVmEgaWZydV9idWZmZXIKK3N0cnVjdC4KK1RoZSB1 c2VyIHN1cHBsaWVkIGJ1ZmZlciBsZW5ndGggc2hvdWxkIGJlIGRlZmluZWQgaW4gdGhlCisu VmEgbGVuZ3RoCitmaWVsZCBvZgorLlZhIGlmcnVfYnVmZmVyCitzdHJ1Y3QgcGFzc2VkIGlu IGFzIHBhcmFtZXRlciwgYW5kIHRoZSBsZW5ndGggd291bGQgaW5jbHVkZQordGhlIHRlcm1p bmF0aW5nIG51bCBjaGFyYWN0ZXIuCisuSXQgRHYgU0lPQ1NJRkRFU0NSCitTZXQgdGhlIGlu dGVyZmFjZSBkZXNjcmlwdGlvbiB0byB0aGUgdmFsdWUgb2YgdGhlCisuVmEgYnVmZmVyCitm aWVsZCBvZgorLlZhIGlmcnVfYnVmZmVyCitzdHJ1Y3QsIHdpdGgKKy5WYSBsZW5ndGgKK2Zp ZWxkIHNwZWNpZnlpbmcgaXRzIGxlbmd0aCAoY291bnRpbmcgdGhlIHRlcm1pbmF0aW5nIG51 bCkuCiAuSXQgRHYgU0lPQ1NJRkZMQUdTCiBTZXQgaW50ZXJmYWNlIGZsYWdzIGZpZWxkLgog SWYgdGhlIGludGVyZmFjZSBpcyBtYXJrZWQgZG93biwKSW5kZXg6IHN5cy9rZXJuL2tlcm5f amFpbC5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9rZXJuL2tlcm5famFpbC5jCShyZXZpc2lv biAyMDI5NzkpCisrKyBzeXMva2Vybi9rZXJuX2phaWwuYwkod29ya2luZyBjb3B5KQpAQCAt MzU5Miw2ICszNTkyLDcgQEAgcHJpc29uX3ByaXZfY2hlY2soc3RydWN0IHVjcmVkICpjcmVk LCBpbnQgcHJpdikKIAljYXNlIFBSSVZfTkVUX1NFVElGTVRVOgogCWNhc2UgUFJJVl9ORVRf U0VUSUZGTEFHUzoKIAljYXNlIFBSSVZfTkVUX1NFVElGQ0FQOgorCWNhc2UgUFJJVl9ORVRf U0VUSUZERVNDUjoKIAljYXNlIFBSSVZfTkVUX1NFVElGTkFNRQk6CiAJY2FzZSBQUklWX05F VF9TRVRJRk1FVFJJQzoKIAljYXNlIFBSSVZfTkVUX1NFVElGUEhZUzoKSW5kZXg6IHN5cy9u ZXQvaWYuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvbmV0L2lmLmMJKHJldmlzaW9uIDIwMjk3 OSkKKysrIHN5cy9uZXQvaWYuYwkod29ya2luZyBjb3B5KQpAQCAtMTA2LDYgKzEwNiwxOCBA QCBTWVNDVExfSU5UKF9uZXRfbGluaywgT0lEX0FVVE8sIGxvZ19saW5rX3N0YXRlX2NoYQog CSZsb2dfbGlua19zdGF0ZV9jaGFuZ2UsIDAsCiAJImxvZyBpbnRlcmZhY2UgbGluayBzdGF0 ZSBjaGFuZ2UgZXZlbnRzIik7CiAKKy8qIEludGVyZmFjZSBkZXNjcmlwdGlvbiAqLworc3Rh dGljIHVuc2lnbmVkIGludCBpZmRlc2NyX21heGxlbiA9IDEwMjQ7CitTWVNDVExfVUlOVChf bmV0LCBPSURfQVVUTywgaWZkZXNjcl9tYXhsZW4sIENUTEZMQUdfUlcsCisJJmlmZGVzY3Jf bWF4bGVuLCAwLAorCSJhZG1pbmlzdHJhdGl2ZSBtYXhpbXVtIGxlbmd0aCBmb3IgaW50ZXJm YWNlIGRlc2NyaXB0aW9uIik7CisKK01BTExPQ19ERUZJTkUoTV9JRkRFU0NSLCAiaWZkZXNj ciIsICJpZm5ldCBkZXNjcmlwdGlvbnMiKTsKKworLyogZ2xvYmFsIHN4IGZvciBub24tY3Jp dGljYWwgcGF0aCBpZmRlc2NyICovCitzdGF0aWMgc3RydWN0IHN4IGlmZGVzY3Jfc3g7CitT WF9TWVNJTklUKGlmZGVzY3Jfc3gsICZpZmRlc2NyX3N4LCAiaWZuZXQgZGVzY3IiKTsKKwog dm9pZAkoKmJzdHBfbGlua3N0YXRlX3ApKHN0cnVjdCBpZm5ldCAqaWZwLCBpbnQgc3RhdGUp Owogdm9pZAkoKm5nX2V0aGVyX2xpbmtfc3RhdGVfcCkoc3RydWN0IGlmbmV0ICppZnAsIGlu dCBzdGF0ZSk7CiB2b2lkCSgqbGFnZ19saW5rc3RhdGVfcCkoc3RydWN0IGlmbmV0ICppZnAs IGludCBzdGF0ZSk7CkBAIC00NDIsNiArNDU0LDggQEAgaWZfZnJlZV9pbnRlcm5hbChzdHJ1 Y3QgaWZuZXQgKmlmcCkKICNpZmRlZiBNQUMKIAltYWNfaWZuZXRfZGVzdHJveShpZnApOwog I2VuZGlmIC8qIE1BQyAqLworCWlmIChpZnAtPmlmX2Rlc2NyaXB0aW9uICE9IE5VTEwpCisJ CWZyZWUoaWZwLT5pZl9kZXNjcmlwdGlvbiwgTV9JRkRFU0NSKTsKIAlJRl9BRkRBVEFfREVT VFJPWShpZnApOwogCUlGX0FERFJfTE9DS19ERVNUUk9ZKGlmcCk7CiAJaWZxX2RlbGV0ZSgm aWZwLT5pZl9zbmQpOwpAQCAtMTk3OSw2ICsxOTkzLDggQEAgaWZod2lvY3RsKHVfbG9uZyBj bWQsIHN0cnVjdCBpZm5ldCAqaWZwLCBjYWRkcl90IGQKIAlpbnQgZXJyb3IgPSAwOwogCWlu dCBuZXdfZmxhZ3MsIHRlbXBfZmxhZ3M7CiAJc2l6ZV90IG5hbWVsZW4sIG9uYW1lbGVuOwor CXNpemVfdCBkZXNjcmxlbjsKKwljaGFyICpkZXNjcmJ1ZiwgKm9kZXNjcmJ1ZjsKIAljaGFy IG5ld19uYW1lW0lGTkFNU0laXTsKIAlzdHJ1Y3QgaWZhZGRyICppZmE7CiAJc3RydWN0IHNv Y2thZGRyX2RsICpzZGw7CkBAIC0yMDE4LDYgKzIwMzQsNTUgQEAgaWZod2lvY3RsKHVfbG9u ZyBjbWQsIHN0cnVjdCBpZm5ldCAqaWZwLCBjYWRkcl90IGQKIAkJaWZyLT5pZnJfcGh5cyA9 IGlmcC0+aWZfcGh5c2ljYWw7CiAJCWJyZWFrOwogCisJY2FzZSBTSU9DR0lGREVTQ1I6CisJ CWVycm9yID0gMDsKKwkJc3hfc2xvY2soJmlmZGVzY3Jfc3gpOworCQlpZiAoaWZwLT5pZl9k ZXNjcmlwdGlvbiA9PSBOVUxMKQorCQkJZXJyb3IgPSBFTk9NU0c7CisJCWVsc2UgeworCQkJ Lyogc3BhY2UgZm9yIHRlcm1pbmF0aW5nIG51bCAqLworCQkJZGVzY3JsZW4gPSBzdHJsZW4o aWZwLT5pZl9kZXNjcmlwdGlvbikgKyAxOworCQkJaWYgKGlmci0+aWZyX2J1ZmZlci5sZW5n dGggPCBkZXNjcmxlbikKKwkJCQllcnJvciA9IEVOQU1FVE9PTE9ORzsKKwkJCWVsc2UKKwkJ CQllcnJvciA9IGNvcHlvdXQoaWZwLT5pZl9kZXNjcmlwdGlvbiwKKwkJCQkgICAgaWZyLT5p ZnJfYnVmZmVyLmJ1ZmZlciwgZGVzY3JsZW4pOworCQl9CisJCXN4X3N1bmxvY2soJmlmZGVz Y3Jfc3gpOworCQlicmVhazsKKworCWNhc2UgU0lPQ1NJRkRFU0NSOgorCQllcnJvciA9IHBy aXZfY2hlY2sodGQsIFBSSVZfTkVUX1NFVElGREVTQ1IpOworCQlpZiAoZXJyb3IpCisJCQly ZXR1cm4gKGVycm9yKTsKKworCQkvKgorCQkgKiBDb3B5IG9ubHkgKGxlbmd0aC0xKSBieXRl cyB0byBtYWtlIHN1cmUgdGhhdAorCQkgKiBpZl9kZXNjcmlwdGlvbiBpcyBhbHdheXMgbnVs IHRlcm1pbmF0ZWQuICBUaGUKKwkJICogbGVuZ3RoIHBhcmFtZXRlciBpcyBzdXBwb3NlZCB0 byBjb3VudCB0aGUKKwkJICogdGVybWluYXRpbmcgbnVsIGluLgorCQkgKi8KKwkJaWYgKGlm ci0+aWZyX2J1ZmZlci5sZW5ndGggPiBpZmRlc2NyX21heGxlbikKKwkJCXJldHVybiAoRU5B TUVUT09MT05HKTsKKworCQlkZXNjcmJ1ZiA9IG1hbGxvYyhpZnItPmlmcl9idWZmZXIubGVu Z3RoLCBNX0lGREVTQ1IsCisJCSAgICBNX1dBSVRPSyB8IE1fWkVSTyk7CisJCWVycm9yID0g Y29weWluKGlmci0+aWZyX2J1ZmZlci5idWZmZXIsIGRlc2NyYnVmLAorCQkgICAgaWZyLT5p ZnJfYnVmZmVyLmxlbmd0aCAtIDEpOworCQlpZiAoZXJyb3IpIHsKKwkJCWZyZWUoZGVzY3Ji dWYsIE1fSUZERVNDUik7CisJCQlicmVhazsKKwkJfQorCisJCXN4X3hsb2NrKCZpZmRlc2Ny X3N4KTsKKwkJb2Rlc2NyYnVmID0gaWZwLT5pZl9kZXNjcmlwdGlvbjsKKwkJaWZwLT5pZl9k ZXNjcmlwdGlvbiA9IGRlc2NyYnVmOworCQlzeF94dW5sb2NrKCZpZmRlc2NyX3N4KTsKKwor CQlnZXRtaWNyb3RpbWUoJmlmcC0+aWZfbGFzdGNoYW5nZSk7CisJCWZyZWUob2Rlc2NyYnVm LCBNX0lGREVTQ1IpOworCQlicmVhazsKKwogCWNhc2UgU0lPQ1NJRkZMQUdTOgogCQllcnJv ciA9IHByaXZfY2hlY2sodGQsIFBSSVZfTkVUX1NFVElGRkxBR1MpOwogCQlpZiAoZXJyb3Ip CkluZGV4OiBzeXMvbmV0L2lmLmgKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL25ldC9pZi5oCShy ZXZpc2lvbiAyMDI5NzkpCisrKyBzeXMvbmV0L2lmLmgJKHdvcmtpbmcgY29weSkKQEAgLTI5 NSw2ICsyOTUsNyBAQCBzdHJ1Y3QJaWZyZXEgewogCQlzdHJ1Y3QJc29ja2FkZHIgaWZydV9h ZGRyOwogCQlzdHJ1Y3QJc29ja2FkZHIgaWZydV9kc3RhZGRyOwogCQlzdHJ1Y3QJc29ja2Fk ZHIgaWZydV9icm9hZGFkZHI7CisJCXN0cnVjdCB7IHNpemVfdCBsZW5ndGg7IGNhZGRyX3QJ YnVmZmVyOyB9IGlmcnVfYnVmZmVyOwogCQlzaG9ydAlpZnJ1X2ZsYWdzWzJdOwogCQlzaG9y dAlpZnJ1X2luZGV4OwogCQlpbnQJaWZydV9qaWQ7CkBAIC0zMDgsNiArMzA5LDcgQEAgc3Ry dWN0CWlmcmVxIHsKICNkZWZpbmUJaWZyX2FkZHIJaWZyX2lmcnUuaWZydV9hZGRyCS8qIGFk ZHJlc3MgKi8KICNkZWZpbmUJaWZyX2RzdGFkZHIJaWZyX2lmcnUuaWZydV9kc3RhZGRyCS8q IG90aGVyIGVuZCBvZiBwLXRvLXAgbGluayAqLwogI2RlZmluZQlpZnJfYnJvYWRhZGRyCWlm cl9pZnJ1LmlmcnVfYnJvYWRhZGRyCS8qIGJyb2FkY2FzdCBhZGRyZXNzICovCisjZGVmaW5l CWlmcl9idWZmZXIJaWZyX2lmcnUuaWZydV9idWZmZXIJLyogdXNlciBzdXBwbGllZCBidWZm ZXIgd2l0aCBpdHMgbGVuZ3RoICovCiAjZGVmaW5lCWlmcl9mbGFncwlpZnJfaWZydS5pZnJ1 X2ZsYWdzWzBdCS8qIGZsYWdzIChsb3cgMTYgYml0cykgKi8KICNkZWZpbmUJaWZyX2ZsYWdz aGlnaAlpZnJfaWZydS5pZnJ1X2ZsYWdzWzFdCS8qIGZsYWdzIChoaWdoIDE2IGJpdHMpICov CiAjZGVmaW5lCWlmcl9qaWQJCWlmcl9pZnJ1LmlmcnVfamlkCS8qIGphaWwvdm5ldCAqLwpJ bmRleDogc3lzL25ldC9pZl92YXIuaAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvbmV0L2lmX3Zh ci5oCShyZXZpc2lvbiAyMDI5NzkpCisrKyBzeXMvbmV0L2lmX3Zhci5oCSh3b3JraW5nIGNv cHkpCkBAIC0yMDMsNyArMjAzLDggQEAgc3RydWN0IGlmbmV0IHsKIAkgKiBiZSB1c2VkIHdp dGggY2FyZSB3aGVyZSBiaW5hcnkgY29tcGF0aWJpbGl0eSBpcyByZXF1aXJlZC4KIAkgKi8K IAljaGFyCSBpZl9jc3BhcmVbM107Ci0Jdm9pZAkqaWZfcHNwYXJlWzhdOworCWNoYXIJKmlm X2Rlc2NyaXB0aW9uOwkvKiBpbnRlcmZhY2UgZGVzY3JpcHRpb24gKi8KKwl2b2lkCSppZl9w c3BhcmVbN107CiAJaW50CWlmX2lzcGFyZVs0XTsKIH07CiAKSW5kZXg6IHN5cy9zeXMvcHJp di5oCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9zeXMvcHJpdi5oCShyZXZpc2lvbiAyMDI5Nzkp CisrKyBzeXMvc3lzL3ByaXYuaAkod29ya2luZyBjb3B5KQpAQCAtMzM1LDYgKzMzNSw3IEBA CiAjZGVmaW5lCVBSSVZfTkVUX0xBR0cJCTQxNQkvKiBBZG1pbmlzdGVyIGxhZ2cgaW50ZXJm YWNlLiAqLwogI2RlZmluZQlQUklWX05FVF9HSUYJCTQxNgkvKiBBZG1pbmlzdGVyIGdpZiBp bnRlcmZhY2UuICovCiAjZGVmaW5lCVBSSVZfTkVUX1NFVElGVk5FVAk0MTcJLyogTW92ZSBp bnRlcmZhY2UgdG8gdm5ldC4gKi8KKyNkZWZpbmUJUFJJVl9ORVRfU0VUSUZERVNDUgk0MTgJ LyogU2V0IGludGVyZmFjZSBkZXNjcmlwdGlvbi4gKi8KIAogLyoKICAqIDgwMi4xMS1yZWxh dGVkIHByaXZpbGVnZXMuCkluZGV4OiBzeXMvc3lzL3NvY2tpby5oCj09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0K LS0tIHN5cy9zeXMvc29ja2lvLmgJKHJldmlzaW9uIDIwMjk3OSkKKysrIHN5cy9zeXMvc29j a2lvLmgJKHdvcmtpbmcgY29weSkKQEAgLTgyLDYgKzgyLDggQEAKICNkZWZpbmUJU0lPQ0dJ Rk1BQwlfSU9XUignaScsIDM4LCBzdHJ1Y3QgaWZyZXEpCS8qIGdldCBJRiBNQUMgbGFiZWwg Ki8KICNkZWZpbmUJU0lPQ1NJRk1BQwkgX0lPVygnaScsIDM5LCBzdHJ1Y3QgaWZyZXEpCS8q IHNldCBJRiBNQUMgbGFiZWwgKi8KICNkZWZpbmUJU0lPQ1NJRk5BTUUJIF9JT1coJ2knLCA0 MCwgc3RydWN0IGlmcmVxKQkvKiBzZXQgSUYgbmFtZSAqLworI2RlZmluZQlTSU9DU0lGREVT Q1IJIF9JT1coJ2knLCA0MSwgc3RydWN0IGlmcmVxKQkvKiBzZXQgaWZuZXQgZGVzY3IgKi8g CisjZGVmaW5lCVNJT0NHSUZERVNDUglfSU9XUignaScsIDQyLCBzdHJ1Y3QgaWZyZXEpCS8q IGdldCBpZm5ldCBkZXNjciAqLyAKIAogI2RlZmluZQlTSU9DQURETVVMVEkJIF9JT1coJ2kn LCA0OSwgc3RydWN0IGlmcmVxKQkvKiBhZGQgbSdjYXN0IGFkZHIgKi8KICNkZWZpbmUJU0lP Q0RFTE1VTFRJCSBfSU9XKCdpJywgNTAsIHN0cnVjdCBpZnJlcSkJLyogZGVsIG0nY2FzdCBh ZGRyICovCg== --------------090205010302020105020607-- From owner-freebsd-net@FreeBSD.ORG Mon Jan 25 22:33:10 2010 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 3C227106566B; Mon, 25 Jan 2010 22:33:10 +0000 (UTC) (envelope-from antoine.brodin.freebsd@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id 4D2738FC0A; Mon, 25 Jan 2010 22:33:09 +0000 (UTC) Received: by fxm27 with SMTP id 27so1352594fxm.3 for ; Mon, 25 Jan 2010 14:33:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=Ndv8+7afie+PjwbMx3xlS7PZXExjtujKYE6YROcyID8=; b=gcRlPPMpMNKv+hrtnw6aNue9DVNMRNpJlgf0vRKEHKteX2EXCVEY+QKcYfwRvmqAby WLPWXQPHm2El6Y2nwKOT/C/KooXaDaJgEtfHN0DdWZUXgfdbyYUz6oHS6KuRO9N6bQh5 4zMU9T6ktmUg23GE8DlRPiEwC5er3zb4l5bzs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=vfeNBpk2+tsKOAwRs7J5qjdUQNz+AcAZjRNhFxTuAcljNFfroAZWSW7xkvGIuYA+LE n4N4iJY/VbLcZyHmvEaqao+w8Yx6tP/XUXFafimCwu6Nf5vR+gAaOZeuzRc10kvd/YAc P2J1yvRBDfzy2BnP/eiVgGFX5y3/T1mDLcQ8M= MIME-Version: 1.0 Sender: antoine.brodin.freebsd@gmail.com Received: by 10.239.193.16 with SMTP id g16mr842004hbi.90.1264458788197; Mon, 25 Jan 2010 14:33:08 -0800 (PST) In-Reply-To: <4B5E16DB.2080203@delphij.net> References: <4B5E16DB.2080203@delphij.net> Date: Mon, 25 Jan 2010 23:33:08 +0100 X-Google-Sender-Auth: 9cf614f7046cbcd6 Message-ID: From: Antoine Brodin To: d@delphij.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Robert Watson , freebsd-net@freebsd.org, delphij@freebsd.org, jhb@freebsd.org Subject: Re: [PATCH] Interface description 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, 25 Jan 2010 22:33:10 -0000 On Mon, Jan 25, 2010 at 11:10 PM, Xin LI wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > I have revised the patchset based on feedback received. =A0This version: > > =A0- Unbreak the case when libpcap is being built for pre-ifdescr world. > =A0- Documents the descr and -descr primitives for ifconfig(8), they are > intended for OpenBSD compatibility. > =A0- Simplify and concentrate memory allocation in ifconfig(8) > =A0- Document the use of nul terminated buffer and the meaning of length > parameter > =A0- Use char* instead of sbuf and simplify the logic in kernel part. > > Hopefully this version would address all problems raised by reviewers. > Comments? A few comments: in contrib/libpcap/inet.c: I think "int s;" can stay under #ifdef SIOCGIFDESCR in sbin/ifconfig/ifconfig.c: do { ... if (...) { descrlen *=3D 2; continue; } ... } while (0); I think there is no retry with larger buffer (while (0)) Perhaps you want while (1) + some breaks Cheers, Antoine From owner-freebsd-net@FreeBSD.ORG Mon Jan 25 23:10:36 2010 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 3A3BB1065670; Mon, 25 Jan 2010 23:10:36 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [IPv6:2001:470:a803::1]) by mx1.freebsd.org (Postfix) with ESMTP id C3D0C8FC18; Mon, 25 Jan 2010 23:10:34 +0000 (UTC) Received: from mail.geekcn.org (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 9E724A580A4; Tue, 26 Jan 2010 07:10:33 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by mail.geekcn.org (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with LMTP id U8I3WTv-9Ype; Tue, 26 Jan 2010 07:10:26 +0800 (CST) Received: from delta.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 8366EA57A21; Tue, 26 Jan 2010 07:10:21 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type; b=KZgynX8PUV6JAPglUnpQgi9RYb5GuAVzwGbS/NiLmbj2IEHjzvq9CmBrjaH46MDN0 PdMIyvctQNOjfvPXXo3pA== Message-ID: <4B5E24D8.2010602@delphij.net> Date: Mon, 25 Jan 2010 15:10:16 -0800 From: Xin LI Organization: The Geek China Organization User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.7) Gecko/20100122 Thunderbird/3.0.1 ThunderBrowse/3.2.8.1 MIME-Version: 1.0 To: Antoine Brodin References: <4B5E16DB.2080203@delphij.net> In-Reply-To: X-Enigmail-Version: 1.0 OpenPGP: id=3FCA37C1; url=http://www.delphij.net/delphij.asc Content-Type: multipart/mixed; boundary="------------040505090008030905010602" Cc: freebsd-net@FreeBSD.ORG, delphij@FreeBSD.ORG, d@delphij.net, jhb@FreeBSD.ORG, Robert Watson Subject: Re: [PATCH] Interface description X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 23:10:36 -0000 This is a multi-part message in MIME format. --------------040505090008030905010602 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2010/01/25 14:33, Antoine Brodin wrote: > On Mon, Jan 25, 2010 at 11:10 PM, Xin LI wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi, >> >> I have revised the patchset based on feedback received. This version: >> >> - Unbreak the case when libpcap is being built for pre-ifdescr world. >> - Documents the descr and -descr primitives for ifconfig(8), they are >> intended for OpenBSD compatibility. >> - Simplify and concentrate memory allocation in ifconfig(8) >> - Document the use of nul terminated buffer and the meaning of length >> parameter >> - Use char* instead of sbuf and simplify the logic in kernel part. >> >> Hopefully this version would address all problems raised by reviewers. >> Comments? > > A few comments: > > in contrib/libpcap/inet.c: > I think "int s;" can stay under #ifdef SIOCGIFDESCR > > in sbin/ifconfig/ifconfig.c: > do { > ... > if (...) { > descrlen *= 2; > continue; > } > ... > } while (0); > I think there is no retry with larger buffer (while (0)) > Perhaps you want while (1) + some breaks Oh right, changed to for (;;) and breaks, thanks for pointing this out. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iQEcBAEBAgAGBQJLXiTYAAoJEATO+BI/yjfBkk0H/2PJDy7TnUVjuWEkEcmFzC1K HNMw7aNGniDBCQyMm66FtXeP01GTEPlpFi2z42x8F/fUt0cYNt0lFTtZvNYrXiYY ceW+T9ktjk4y5Ysixsz7L/ei4ItVy2z7WsiHMkck9zw0SUfao2FWc42cFJnb6zZD myoLe9yR41E5KeZBOqqu+9L9ZY1vB24v5o3/QDCeleLRbLelrRrfGjy5NZm2lIQU W8911uKkxwmcajPCvAl0uLzd9zTSXlQLAAflceO/sZMqeOxFBEXsZAk6U8Bb/3Xl WJY6aAI98fiFP1+DtIivQqj3r7SyWmCjd5dfxGH0o1uvjgF4KSoGdZ6mc3daWEM= =ssxD -----END PGP SIGNATURE----- --------------040505090008030905010602 Content-Type: text/plain; name="ifdescr.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ifdescr.diff" Index: contrib/libpcap/inet.c =================================================================== --- contrib/libpcap/inet.c (revision 202988) +++ contrib/libpcap/inet.c (working copy) @@ -401,11 +401,16 @@ add_addr_to_iflist(pcap_if_t **alldevs, const char pcap_if_t *curdev; char *description = NULL; pcap_addr_t *curaddr, *prevaddr, *nextaddr; + int s; #ifdef SIOCGIFDESCR struct ifreq ifrdesc; +#ifndef IFDESCRSIZE +#define _IFDESCRSIZE 64 + char ifdescr[_IFDESCRSIZE]; +#else char ifdescr[IFDESCRSIZE]; - int s; #endif +#endif #ifdef SIOCGIFDESCR /* @@ -413,12 +418,17 @@ add_addr_to_iflist(pcap_if_t **alldevs, const char */ memset(&ifrdesc, 0, sizeof ifrdesc); strlcpy(ifrdesc.ifr_name, name, sizeof ifrdesc.ifr_name); +#ifdef __FreeBSD__ + ifrdesc.ifr_buffer.buffer = ifdescr; + ifrdesc.ifr_buffer.length = sizeof(ifdescr); +#else ifrdesc.ifr_data = (caddr_t)&ifdescr; +#endif s = socket(AF_INET, SOCK_DGRAM, 0); if (s >= 0) { if (ioctl(s, SIOCGIFDESCR, &ifrdesc) == 0 && - strlen(ifrdesc.ifr_data) != 0) - description = ifrdesc.ifr_data; + strlen(ifdescr) != 0) + description = ifdescr; close(s); } #endif Index: sbin/ifconfig/ifconfig.8 =================================================================== --- sbin/ifconfig/ifconfig.8 (revision 202988) +++ sbin/ifconfig/ifconfig.8 (working copy) @@ -28,7 +28,7 @@ .\" From: @(#)ifconfig.8 8.3 (Berkeley) 1/5/94 .\" $FreeBSD$ .\" -.Dd September 23, 2009 +.Dd January 25, 2010 .Dt IFCONFIG 8 .Os .Sh NAME @@ -258,6 +258,12 @@ Disable permanently promiscuous mode. Another name for the .Fl alias parameter. +.It Cm description Ar value , Cm descr Ar value +Specify a description of the interface. +This can be used to label interfaces in situations where they may +otherwise be difficult to distinguish. +.It Cm -description , Cm -descr +Clear the interface description. .It Cm down Mark an interface .Dq down . @@ -2512,6 +2518,10 @@ Configure the interface to use 100baseTX, full duplex Ethernet media options: .Dl # ifconfig xl0 media 100baseTX mediaopt full-duplex .Pp +Label the em0 interface as an uplink: +.Pp +.Dl # ifconfig em0 description \&"Uplink to Gigabit Switch 2\&" +.Pp Create the software network interface .Li gif1 : .Dl # ifconfig gif1 create Index: sbin/ifconfig/ifconfig.c =================================================================== --- sbin/ifconfig/ifconfig.c (revision 202988) +++ sbin/ifconfig/ifconfig.c (working copy) @@ -44,7 +44,6 @@ static const char rcsid[] = #include #include #include -#include #include #include #include @@ -83,6 +82,8 @@ static const char rcsid[] = struct ifreq ifr; char name[IFNAMSIZ]; +char *descr = NULL; +size_t descrlen = 64; int setaddr; int setmask; int doalias; @@ -838,6 +839,35 @@ setifname(const char *val, int dummy __unused, int free(newname); } +/* ARGSUSED */ +static void +setifdescr(const char *val, int dummy __unused, int s, + const struct afswtch *afp) +{ + char *newdescr; + + newdescr = strdup(val); + if (newdescr == NULL) { + warn("no memory to set ifdescr"); + return; + } + + ifr.ifr_buffer.buffer = newdescr; + ifr.ifr_buffer.length = strlen(newdescr) + 1; + if (ioctl(s, SIOCSIFDESCR, (caddr_t)&ifr) < 0) + warn("ioctl (set descr)"); + + free(newdescr); +} + +/* ARGSUSED */ +static void +unsetifdescr(const char *val, int value, int s, const struct afswtch *afp) +{ + + setifdescr("", 0, s, 0); +} + #define IFFBITS \ "\020\1UP\2BROADCAST\3DEBUG\4LOOPBACK\5POINTOPOINT\6SMART\7RUNNING" \ "\10NOARP\11PROMISC\12ALLMULTI\13OACTIVE\14SIMPLEX\15LINK0\16LINK1\17LINK2" \ @@ -882,6 +912,25 @@ status(const struct afswtch *afp, const struct soc printf(" mtu %d", ifr.ifr_mtu); putchar('\n'); + for (;;) { + if ((descr = reallocf(descr, descrlen)) != NULL) { + ifr.ifr_buffer.buffer = descr; + ifr.ifr_buffer.length = descrlen; + if (ioctl(s, SIOCGIFDESCR, &ifr) == 0) { + if (strlen(descr) > 0) + printf("\tdescription: %s\n", descr); + break; + } else if (errno == ENAMETOOLONG) + descrlen *= 2; + else + break; + } else { + warn("unable to allocate memory for interface" + "description"); + break; + } + }; + if (ioctl(s, SIOCGIFCAP, (caddr_t)&ifr) == 0) { if (ifr.ifr_curcap != 0) { printb("\toptions", ifr.ifr_curcap, IFCAPBITS); @@ -1051,6 +1100,10 @@ static struct cmd basic_cmds[] = { DEF_CMD("-arp", IFF_NOARP, setifflags), DEF_CMD("debug", IFF_DEBUG, setifflags), DEF_CMD("-debug", -IFF_DEBUG, setifflags), + DEF_CMD_ARG("description", setifdescr), + DEF_CMD_ARG("descr", setifdescr), + DEF_CMD("-description", 0, unsetifdescr), + DEF_CMD("-descr", 0, unsetifdescr), DEF_CMD("promisc", IFF_PPROMISC, setifflags), DEF_CMD("-promisc", -IFF_PPROMISC, setifflags), DEF_CMD("add", IFF_UP, notealias), Index: share/man/man4/netintro.4 =================================================================== --- share/man/man4/netintro.4 (revision 202988) +++ share/man/man4/netintro.4 (working copy) @@ -32,7 +32,7 @@ .\" @(#)netintro.4 8.2 (Berkeley) 11/30/93 .\" $FreeBSD$ .\" -.Dd June 18, 2004 +.Dd January 25, 2010 .Dt NETINTRO 4 .Os .Sh NAME @@ -204,6 +204,7 @@ struct ifreq { struct sockaddr ifru_addr; struct sockaddr ifru_dstaddr; struct sockaddr ifru_broadaddr; + struct { size_t length; caddr_t buffer; } ifru_buffer; short ifru_flags[2]; short ifru_index; int ifru_metric; @@ -216,6 +217,7 @@ struct ifreq { #define ifr_addr ifr_ifru.ifru_addr /* address */ #define ifr_dstaddr ifr_ifru.ifru_dstaddr /* other end of p-to-p link */ #define ifr_broadaddr ifr_ifru.ifru_broadaddr /* broadcast address */ +#define ifr_buffer ifr_ifru.ifru_buffer /* user supplied buffer with its length */ #define ifr_flags ifr_ifru.ifru_flags[0] /* flags (low 16 bits) */ #define ifr_flagshigh ifr_ifru.ifru_flags[1] /* flags (high 16 bits) */ #define ifr_metric ifr_ifru.ifru_metric /* metric */ @@ -277,6 +279,26 @@ and fields of the .Vt ifreq structure, respectively. +.It Dv SIOCGIFDESCR +Get the interface description, returned in the +.Va buffer +field of +.Va ifru_buffer +struct. +The user supplied buffer length should be defined in the +.Va length +field of +.Va ifru_buffer +struct passed in as parameter, and the length would include +the terminating nul character. +.It Dv SIOCSIFDESCR +Set the interface description to the value of the +.Va buffer +field of +.Va ifru_buffer +struct, with +.Va length +field specifying its length (counting the terminating nul). .It Dv SIOCSIFFLAGS Set interface flags field. If the interface is marked down, Index: sys/kern/kern_jail.c =================================================================== --- sys/kern/kern_jail.c (revision 202988) +++ sys/kern/kern_jail.c (working copy) @@ -3592,6 +3592,7 @@ prison_priv_check(struct ucred *cred, int priv) case PRIV_NET_SETIFMTU: case PRIV_NET_SETIFFLAGS: case PRIV_NET_SETIFCAP: + case PRIV_NET_SETIFDESCR: case PRIV_NET_SETIFNAME : case PRIV_NET_SETIFMETRIC: case PRIV_NET_SETIFPHYS: Index: sys/net/if.c =================================================================== --- sys/net/if.c (revision 202988) +++ sys/net/if.c (working copy) @@ -106,6 +106,18 @@ SYSCTL_INT(_net_link, OID_AUTO, log_link_state_cha &log_link_state_change, 0, "log interface link state change events"); +/* Interface description */ +static unsigned int ifdescr_maxlen = 1024; +SYSCTL_UINT(_net, OID_AUTO, ifdescr_maxlen, CTLFLAG_RW, + &ifdescr_maxlen, 0, + "administrative maximum length for interface description"); + +MALLOC_DEFINE(M_IFDESCR, "ifdescr", "ifnet descriptions"); + +/* global sx for non-critical path ifdescr */ +static struct sx ifdescr_sx; +SX_SYSINIT(ifdescr_sx, &ifdescr_sx, "ifnet descr"); + void (*bstp_linkstate_p)(struct ifnet *ifp, int state); void (*ng_ether_link_state_p)(struct ifnet *ifp, int state); void (*lagg_linkstate_p)(struct ifnet *ifp, int state); @@ -442,6 +454,8 @@ if_free_internal(struct ifnet *ifp) #ifdef MAC mac_ifnet_destroy(ifp); #endif /* MAC */ + if (ifp->if_description != NULL) + free(ifp->if_description, M_IFDESCR); IF_AFDATA_DESTROY(ifp); IF_ADDR_LOCK_DESTROY(ifp); ifq_delete(&ifp->if_snd); @@ -1979,6 +1993,8 @@ ifhwioctl(u_long cmd, struct ifnet *ifp, caddr_t d int error = 0; int new_flags, temp_flags; size_t namelen, onamelen; + size_t descrlen; + char *descrbuf, *odescrbuf; char new_name[IFNAMSIZ]; struct ifaddr *ifa; struct sockaddr_dl *sdl; @@ -2018,6 +2034,55 @@ ifhwioctl(u_long cmd, struct ifnet *ifp, caddr_t d ifr->ifr_phys = ifp->if_physical; break; + case SIOCGIFDESCR: + error = 0; + sx_slock(&ifdescr_sx); + if (ifp->if_description == NULL) + error = ENOMSG; + else { + /* space for terminating nul */ + descrlen = strlen(ifp->if_description) + 1; + if (ifr->ifr_buffer.length < descrlen) + error = ENAMETOOLONG; + else + error = copyout(ifp->if_description, + ifr->ifr_buffer.buffer, descrlen); + } + sx_sunlock(&ifdescr_sx); + break; + + case SIOCSIFDESCR: + error = priv_check(td, PRIV_NET_SETIFDESCR); + if (error) + return (error); + + /* + * Copy only (length-1) bytes to make sure that + * if_description is always nul terminated. The + * length parameter is supposed to count the + * terminating nul in. + */ + if (ifr->ifr_buffer.length > ifdescr_maxlen) + return (ENAMETOOLONG); + + descrbuf = malloc(ifr->ifr_buffer.length, M_IFDESCR, + M_WAITOK | M_ZERO); + error = copyin(ifr->ifr_buffer.buffer, descrbuf, + ifr->ifr_buffer.length - 1); + if (error) { + free(descrbuf, M_IFDESCR); + break; + } + + sx_xlock(&ifdescr_sx); + odescrbuf = ifp->if_description; + ifp->if_description = descrbuf; + sx_xunlock(&ifdescr_sx); + + getmicrotime(&ifp->if_lastchange); + free(odescrbuf, M_IFDESCR); + break; + case SIOCSIFFLAGS: error = priv_check(td, PRIV_NET_SETIFFLAGS); if (error) Index: sys/net/if.h =================================================================== --- sys/net/if.h (revision 202988) +++ sys/net/if.h (working copy) @@ -295,6 +295,7 @@ struct ifreq { struct sockaddr ifru_addr; struct sockaddr ifru_dstaddr; struct sockaddr ifru_broadaddr; + struct { size_t length; caddr_t buffer; } ifru_buffer; short ifru_flags[2]; short ifru_index; int ifru_jid; @@ -308,6 +309,7 @@ struct ifreq { #define ifr_addr ifr_ifru.ifru_addr /* address */ #define ifr_dstaddr ifr_ifru.ifru_dstaddr /* other end of p-to-p link */ #define ifr_broadaddr ifr_ifru.ifru_broadaddr /* broadcast address */ +#define ifr_buffer ifr_ifru.ifru_buffer /* user supplied buffer with its length */ #define ifr_flags ifr_ifru.ifru_flags[0] /* flags (low 16 bits) */ #define ifr_flagshigh ifr_ifru.ifru_flags[1] /* flags (high 16 bits) */ #define ifr_jid ifr_ifru.ifru_jid /* jail/vnet */ Index: sys/net/if_var.h =================================================================== --- sys/net/if_var.h (revision 202988) +++ sys/net/if_var.h (working copy) @@ -203,7 +203,8 @@ struct ifnet { * be used with care where binary compatibility is required. */ char if_cspare[3]; - void *if_pspare[8]; + char *if_description; /* interface description */ + void *if_pspare[7]; int if_ispare[4]; }; Index: sys/sys/priv.h =================================================================== --- sys/sys/priv.h (revision 202988) +++ sys/sys/priv.h (working copy) @@ -335,6 +335,7 @@ #define PRIV_NET_LAGG 415 /* Administer lagg interface. */ #define PRIV_NET_GIF 416 /* Administer gif interface. */ #define PRIV_NET_SETIFVNET 417 /* Move interface to vnet. */ +#define PRIV_NET_SETIFDESCR 418 /* Set interface description. */ /* * 802.11-related privileges. Index: sys/sys/sockio.h =================================================================== --- sys/sys/sockio.h (revision 202988) +++ sys/sys/sockio.h (working copy) @@ -82,6 +82,8 @@ #define SIOCGIFMAC _IOWR('i', 38, struct ifreq) /* get IF MAC label */ #define SIOCSIFMAC _IOW('i', 39, struct ifreq) /* set IF MAC label */ #define SIOCSIFNAME _IOW('i', 40, struct ifreq) /* set IF name */ +#define SIOCSIFDESCR _IOW('i', 41, struct ifreq) /* set ifnet descr */ +#define SIOCGIFDESCR _IOWR('i', 42, struct ifreq) /* get ifnet descr */ #define SIOCADDMULTI _IOW('i', 49, struct ifreq) /* add m'cast addr */ #define SIOCDELMULTI _IOW('i', 50, struct ifreq) /* del m'cast addr */ --------------040505090008030905010602-- From owner-freebsd-net@FreeBSD.ORG Tue Jan 26 02:51:11 2010 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 3B136106568F for ; Tue, 26 Jan 2010 02:51:11 +0000 (UTC) (envelope-from yyq05120512@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by mx1.freebsd.org (Postfix) with ESMTP id D56DD8FC15 for ; Tue, 26 Jan 2010 02:51:10 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 5so121100qwi.7 for ; Mon, 25 Jan 2010 18:51:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=6AvZhWhcXqC0sNsRW4Jni5pFP2qzM6ruFX9l09qrLoQ=; b=kGaPy8Ntg+uDZ9G1U6cojWejbMYhIDbr7QBD1XsrKHiC4xBMmC7TgCkePvxlkhMlQI xRUHtWadJQQxVA/dIojjqQA4VOdaUTwpUeMHG74x4ufrfMJzVLXm8Vs8y+gV5wMhP9Z8 sEq1jSaoRdtUHT6FWSbbS88ATG8h9LguahZQg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=R4l+rq0udQXkdt1xZLKzb65mAB/1aNkHx/1HQSCGtknmOp+aKEwdQ8wy2Dck4NY4Pb SICWh6uNkVRujG31ielyR5oeBgKEUBhePyIH26VdA6kjn/5SFW4g5nYrPcsOMxgVPCaV oWALz7es54AyckhmMfhihd9RDmtHpt58J36g8= MIME-Version: 1.0 Received: by 10.224.65.37 with SMTP id g37mr4650071qai.101.1264474270157; Mon, 25 Jan 2010 18:51:10 -0800 (PST) In-Reply-To: <20100121093221.GA23339@valeria.zesoi.fer.hr> References: <81e37cce1001201752t670daba3sbeb4e7b5e3035bf7@mail.gmail.com> <20100121093221.GA23339@valeria.zesoi.fer.hr> Date: Tue, 26 Jan 2010 10:51:10 +0800 Message-ID: <81e37cce1001251851t4881044fkda7f51092e954aef@mail.gmail.com> From: yanqing you To: iprebeg@freebsd.org X-Mailman-Approved-At: Tue, 26 Jan 2010 03:13:16 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: freeBSD8.0 multicast routing 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: Tue, 26 Jan 2010 02:51:11 -0000 Thank you all that give me help,I configure mrouted with the handbook and update to 8.0 stable ,but it cannot multicast routing yet. please give me more advice.This is the steps of my configuration following: 1.configure the kernel options,add the following options MROUTING 2.build and install new kernel 3.run mrouted I think the mrouted.conf is not correct configured,please give me some advice how to configure it . 2010/1/21 > I belive that mrouting in 8.o is broken due to some kind of paranoid > filter that drops IGMP joins, can't rememeber exact problem. Anyway, bms > commited patch to -STABLE, so maybe you may need to pull up kernel > source from cvs. > > Ivor > > On Thu, Jan 21, 2010 at 09:52:56AM +0800, yanqing you wrote: > > how to enable multicast routing in freeBSD8.0,please give the steps of > > configuration. > > _______________________________________________ > > 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 Jan 26 08:59:37 2010 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 CB0D71065696 for ; Tue, 26 Jan 2010 08:59:37 +0000 (UTC) (envelope-from iprebeg@freebsd.org) Received: from maja.zesoi.fer.hr (maja.zesoi.fer.hr [161.53.64.3]) by mx1.freebsd.org (Postfix) with ESMTP id 82F578FC16 for ; Tue, 26 Jan 2010 08:59:37 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by maja.zesoi.fer.hr (Postfix) with ESMTP id 8C1EE9FD7A; Tue, 26 Jan 2010 09:59:35 +0100 (CET) Received: from maja.zesoi.fer.hr ([127.0.0.1]) by localhost (maja.zesoi.fer.hr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SkzK2kswV3G6; Tue, 26 Jan 2010 09:59:33 +0100 (CET) Received: from valeria.zesoi.fer.hr (valeria.zesoi.fer.hr [161.53.64.29]) by maja.zesoi.fer.hr (Postfix) with ESMTP id 3BEA29FD74; Tue, 26 Jan 2010 09:59:33 +0100 (CET) Date: Tue, 26 Jan 2010 09:56:58 +0100 From: iprebeg@freebsd.org To: yanqing you Message-ID: <20100126085658.GA19130@valeria.zesoi.fer.hr> References: <81e37cce1001201752t670daba3sbeb4e7b5e3035bf7@mail.gmail.com> <20100121093221.GA23339@valeria.zesoi.fer.hr> <81e37cce1001251851t4881044fkda7f51092e954aef@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cNdxnHkX5QqsyA0e" Content-Disposition: inline In-Reply-To: <81e37cce1001251851t4881044fkda7f51092e954aef@mail.gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-net@freebsd.org Subject: Re: freeBSD8.0 multicast routing 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: Tue, 26 Jan 2010 08:59:37 -0000 --cNdxnHkX5QqsyA0e Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Honestly, I never gave many credits to mrouted. I do all testing of my mcast stuff with xorp. If you want, I'll send you some examples of config.boot files for xorp, they can look mess if you use it for first time.=20 If you want to stick with mrouted, can you describe your problem with a bit more details? What do you use to generate mcast traffic? What happens with it and what not? There are lot of stuff which can go wrong here. Maybe first one which you can look at is wheather your outgoing packets have TTL > 1 and increase it properly. That happened to me with mcast-tools (mcastsend & mcastrecv). On Tue, Jan 26, 2010 at 10:51:10AM +0800, yanqing you wrote: > Thank you all that give me help,I configure mrouted with the handbook and > update to 8.0 stable ,but it cannot multicast routing yet. please give me > more advice.This is the steps of my configuration following: > 1.configure the kernel options,add the following > options MROUTING > 2.build and install new kernel > 3.run mrouted > I think the mrouted.conf is not correct configured,please give me some > advice how to configure it . >=20 > 2010/1/21 >=20 > > I belive that mrouting in 8.o is broken due to some kind of paranoid > > filter that drops IGMP joins, can't rememeber exact problem. Anyway, bms > > commited patch to -STABLE, so maybe you may need to pull up kernel > > source from cvs. > > > > Ivor > > > > On Thu, Jan 21, 2010 at 09:52:56AM +0800, yanqing you wrote: > > > how to enable multicast routing in freeBSD8.0,please give the steps of > > > configuration. > > > _______________________________________________ > > > 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" --cNdxnHkX5QqsyA0e Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAkterloACgkQHE64Rwv9Fd7BGQCghEKijOLeO1n2M21pz8bqi9sn QSoAoIJrYnUPG17T7kupqg+sQvVYh5C4 =Wqj+ -----END PGP SIGNATURE----- --cNdxnHkX5QqsyA0e-- From owner-freebsd-net@FreeBSD.ORG Tue Jan 26 10:10:17 2010 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 CBC33106566C; Tue, 26 Jan 2010 10:10:17 +0000 (UTC) (envelope-from shteryana@gmail.com) Received: from mail-ew0-f218.google.com (mail-ew0-f218.google.com [209.85.219.218]) by mx1.freebsd.org (Postfix) with ESMTP id 378558FC19; Tue, 26 Jan 2010 10:10:16 +0000 (UTC) Received: by ewy10 with SMTP id 10so3722250ewy.3 for ; Tue, 26 Jan 2010 02:10:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:reply-to:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=ioHKeXNuR6ThiPhqu1QLMT0vbO17fkfcuQ7v9qrZ8EI=; b=gj1aO9Taex05QBGs7uUpDu5WA+6ejSFF/r3PQwcChCCZyJlcC2EaIUZuzE/JKbsmjF rwiewJII1Hud0GB48t33hNhS+gyDlAeFg7oqxCMRSXStSmHGonD3LbHyZBmYbHNMfVwI 2CoOCIZju8QxEdZMJoMtdrEcWoE1c2VYoWTLI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:reply-to:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=x7k0YfQ0SRY66I0mhAtLRBya0avEHaWXmbUpXo2f6+VoheAzeVU+AvkrjN+f85k5WJ QpqUsUYXONhtcNhIg+u6/hRE0/tUgOngcQDlo/e6TmJLBx82EDwa91fS6zRnL4QfVuDr AHYYBgCxHz56hwKvawJL9HO6L/JWY8E4dO60Q= MIME-Version: 1.0 Sender: shteryana@gmail.com Received: by 10.213.25.67 with SMTP id y3mr4904539ebb.73.1264500615254; Tue, 26 Jan 2010 02:10:15 -0800 (PST) In-Reply-To: <20100123234635.GH20753@michelle.cdnetworks.com> References: <201001221959.o0MJxnIs016854@freefall.freebsd.org> <61b573981001230542l59a9ab6y26514a213bfbdb67@mail.gmail.com> <20100123234635.GH20753@michelle.cdnetworks.com> Date: Tue, 26 Jan 2010 12:10:15 +0200 X-Google-Sender-Auth: e307a175625b7757 Message-ID: <61b573981001260210x7954a449ra1a96789a975a57@mail.gmail.com> From: Shteryana Shopova To: pyunyh@gmail.com Content-Type: text/plain; charset=UTF-8 Cc: freebsd-net@freebsd.org, yongari@freebsd.org Subject: Re: i386/142974: [patch][net][if_re] Teach the if_re driver to properly recognize hardware revisions with non-zero MAC rev. bits X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: syrinx@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 10:10:17 -0000 Hi, > > Anyway, would you try attached patch? I'm not entirely sure whether > my patch is correct or not but I just added minimal support for > the new controller(RTL8103E series). RTL8103E seems to have > additional registers related with power control/WOL so I'm not sure > the patch is enough to make suspend/resume/WOL work too. > Attached patch seems to works - at least the driver attaches correctly, the interface gets an IP address via DHCP, no driver errors reported in /var/log/messages. cheers, Shteryana From owner-freebsd-net@FreeBSD.ORG Tue Jan 26 16:41:03 2010 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 994A61065693; Tue, 26 Jan 2010 16:41:03 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 6D8EF8FC12; Tue, 26 Jan 2010 16:41:03 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 07E7246B2C; Tue, 26 Jan 2010 11:41:03 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 564C08A01F; Tue, 26 Jan 2010 11:41:02 -0500 (EST) From: John Baldwin To: d@delphij.net Date: Tue, 26 Jan 2010 11:40:50 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20100120; KDE/4.3.1; amd64; ; ) References: <4B5E16DB.2080203@delphij.net> In-Reply-To: <4B5E16DB.2080203@delphij.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201001261140.51006.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 26 Jan 2010 11:41:02 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: delphij@freebsd.org, freebsd-net@freebsd.org, Robert Watson Subject: Re: [PATCH] Interface description 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, 26 Jan 2010 16:41:03 -0000 On Monday 25 January 2010 5:10:35 pm Xin LI wrote: > Hi, > > I have revised the patchset based on feedback received. This version: > > - Unbreak the case when libpcap is being built for pre-ifdescr world. > - Documents the descr and -descr primitives for ifconfig(8), they are > intended for OpenBSD compatibility. > - Simplify and concentrate memory allocation in ifconfig(8) > - Document the use of nul terminated buffer and the meaning of length > parameter > - Use char* instead of sbuf and simplify the logic in kernel part. > > Hopefully this version would address all problems raised by reviewers. > Comments? I just have two suggestions/comments: @@ -295,6 +295,7 @@ struct ifreq { struct sockaddr ifru_addr; struct sockaddr ifru_dstaddr; struct sockaddr ifru_broadaddr; + struct { size_t length; caddr_t buffer; } ifru_buffer; short ifru_flags[2]; short ifru_index; int ifru_jid; I prefer to not have this all on one line, but to instead be: struct sockaddr ifru_addr; struct sockaddr ifru_dstaddr; struct sockaddr ifru_broadaddr; struct { size_t length; caddr_t buffer; } ifru_buffer; Even better would be to actually define a separate type earlier in the file I think: struct ifreq_buffer { void *buffer; size_t length; }; and then just use: struct ifreq_buffer ifru_buffer; I think caddr_t is deprecated in favor of void * for new APIs at least. Second, it would be nice if SIOCGIFDESCR provided length feedback to userland similar to sysctl(3). Maybe change the code to set ifr.ifr_buffer.length to the required length when returning ENAMETOOLONG. Userland can then just skip to that length directly, or instead use an idiom similar to sysctl where it does the following: ifr.ifr_buffer.buffer = NULL; ifr.ifr_buffer.length = 0; for (;;) { if (ioctl(s, SIOCGIFDESCR, &ifr) == 0) { /* have descr in ifr.ifr_buffer.buffer */ } else if (errno == ENAMETOOLONG) { ifr.ifr_buffer.buffer = reallocf(ifr.ifr_buffer.buffer, ifr.ifr_buffer.length); if (ifr.ifr_buffer.buffer == NULL) { /* handle realloc() failure, break */ } continue; } else { /* handle error, break */ } } -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Tue Jan 26 20:21:57 2010 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 A2854106566B; Tue, 26 Jan 2010 20:21:57 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [IPv6:2001:470:a803::1]) by mx1.freebsd.org (Postfix) with ESMTP id 1A10A8FC08; Tue, 26 Jan 2010 20:21:56 +0000 (UTC) Received: from mail.geekcn.org (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 382C0A5AE8C; Wed, 27 Jan 2010 04:21:55 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by mail.geekcn.org (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with LMTP id R79j-9b4K3Ok; Wed, 27 Jan 2010 04:21:47 +0800 (CST) Received: from delta.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id BF4B5A5ADD2; Wed, 27 Jan 2010 04:21:45 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type; b=XNDi7BZFskz4V4BpX1PdHNbikHststIoInqyjW3gKJcvR0xphUIbAFLKxgYKW2Oyy iWx1c1sXzMvT7zsPrks1w== Message-ID: <4B5F4ED6.1070400@delphij.net> Date: Tue, 26 Jan 2010 12:21:42 -0800 From: Xin LI Organization: The Geek China Organization User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.7) Gecko/20100122 Thunderbird/3.0.1 ThunderBrowse/3.2.8.1 MIME-Version: 1.0 To: John Baldwin References: <4B5E16DB.2080203@delphij.net> <201001261140.51006.jhb@freebsd.org> In-Reply-To: <201001261140.51006.jhb@freebsd.org> X-Enigmail-Version: 1.0 OpenPGP: id=3FCA37C1; url=http://www.delphij.net/delphij.asc Content-Type: multipart/mixed; boundary="------------010809040603030808010100" Cc: Robert Watson , freebsd-net@freebsd.org, d@delphij.net, delphij@freebsd.org Subject: Re: [PATCH] Interface description X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 20:21:57 -0000 This is a multi-part message in MIME format. --------------010809040603030808010100 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2010/01/26 08:40, John Baldwin wrote: > I just have two suggestions/comments: > @@ -295,6 +295,7 @@ struct ifreq { [...] > I prefer to not have this all on one line, but to instead be: [...] > Even better would be to actually define a separate type earlier > in the file I think: [...] > I think caddr_t is deprecated in favor of void * for new APIs at least. I have split it into another type and used void *, also updated the manual page. > Second, it would be nice if SIOCGIFDESCR provided length feedback to userland > similar to sysctl(3). Maybe change the code to set ifr.ifr_buffer.length to > the required length when returning ENAMETOOLONG. Userland can then just skip > to that length directly, or instead use an idiom similar to sysctl where it > does the following: Done in a slightly different way. It seems to be slightly wasteful (not a big deal, though) to ioctl every time to obtain the length, so I used an arbitrary number (2^6) and make the program to adapt to larger number if kernel gave feedback with ENAMETOOLONG, and the buffer/length would be used the next call. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iQEcBAEBAgAGBQJLX07VAAoJEATO+BI/yjfB23EIAJPNUBPSW7H1OEGMJgMvDnql 0m/RiZzjgnld5S380ijZNAw4f02ZTT8hUuMM6tHeiVaVwW9JciRlo4EOy6Y0pn8L yUBKN4XCkn1T1HPnBRrEkauFl0E/PwD9tdn0Y//qTO1TFyzCR0vqqg7bm1Fw7uEN dH0lYa4mlbgu47uXoJ/uAhqff0vAgIClthLv3EGX0yj6Kb/UBy9USLZfVP3JMMCJ sRqDZNO20phfa+B6jhsVNgFGorYgHrn/K4sr89b86a9ubCR/FtESfMVsqKvoFWLZ YHVq0IJ5GTpezkcN9aAqRb5hCdw09cGcufFZO6ByxksBDuBRQb9GyuS8w+l2TPk= =uWo0 -----END PGP SIGNATURE----- --------------010809040603030808010100 Content-Type: text/plain; name="ifdescr-20100126.diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ifdescr-20100126.diff" SW5kZXg6IGNvbnRyaWIvbGlicGNhcC9pbmV0LmMKPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gY29udHJp Yi9saWJwY2FwL2luZXQuYwkocmV2aXNpb24gMjAzMDIxKQorKysgY29udHJpYi9saWJwY2Fw L2luZXQuYwkod29ya2luZyBjb3B5KQpAQCAtNDAxLDExICs0MDEsMTYgQEAgYWRkX2FkZHJf dG9faWZsaXN0KHBjYXBfaWZfdCAqKmFsbGRldnMsIGNvbnN0IGNoYXIKIAlwY2FwX2lmX3Qg KmN1cmRldjsKIAljaGFyICpkZXNjcmlwdGlvbiA9IE5VTEw7CiAJcGNhcF9hZGRyX3QgKmN1 cmFkZHIsICpwcmV2YWRkciwgKm5leHRhZGRyOworCWludCBzOwogI2lmZGVmIFNJT0NHSUZE RVNDUgogCXN0cnVjdCBpZnJlcSBpZnJkZXNjOworI2lmbmRlZiBJRkRFU0NSU0laRQorI2Rl ZmluZSBfSUZERVNDUlNJWkUgNjQKKwljaGFyIGlmZGVzY3JbX0lGREVTQ1JTSVpFXTsKKyNl bHNlCiAJY2hhciBpZmRlc2NyW0lGREVTQ1JTSVpFXTsKLQlpbnQgczsKICNlbmRpZgorI2Vu ZGlmCiAKICNpZmRlZiBTSU9DR0lGREVTQ1IKIAkvKgpAQCAtNDEzLDEyICs0MTgsMTcgQEAg YWRkX2FkZHJfdG9faWZsaXN0KHBjYXBfaWZfdCAqKmFsbGRldnMsIGNvbnN0IGNoYXIKIAkg Ki8KIAltZW1zZXQoJmlmcmRlc2MsIDAsIHNpemVvZiBpZnJkZXNjKTsKIAlzdHJsY3B5KGlm cmRlc2MuaWZyX25hbWUsIG5hbWUsIHNpemVvZiBpZnJkZXNjLmlmcl9uYW1lKTsKKyNpZmRl ZiBfX0ZyZWVCU0RfXworCWlmcmRlc2MuaWZyX2J1ZmZlci5idWZmZXIgPSBpZmRlc2NyOwor CWlmcmRlc2MuaWZyX2J1ZmZlci5sZW5ndGggPSBzaXplb2YoaWZkZXNjcik7CisjZWxzZQog CWlmcmRlc2MuaWZyX2RhdGEgPSAoY2FkZHJfdCkmaWZkZXNjcjsKKyNlbmRpZgogCXMgPSBz b2NrZXQoQUZfSU5FVCwgU09DS19ER1JBTSwgMCk7CiAJaWYgKHMgPj0gMCkgewogCQlpZiAo aW9jdGwocywgU0lPQ0dJRkRFU0NSLCAmaWZyZGVzYykgPT0gMCAmJgotCQkgICAgc3RybGVu KGlmcmRlc2MuaWZyX2RhdGEpICE9IDApCi0JCQlkZXNjcmlwdGlvbiA9IGlmcmRlc2MuaWZy X2RhdGE7CisJCSAgICBzdHJsZW4oaWZkZXNjcikgIT0gMCkKKwkJCWRlc2NyaXB0aW9uID0g aWZkZXNjcjsKIAkJY2xvc2Uocyk7CiAJfQogI2VuZGlmCkluZGV4OiBzYmluL2lmY29uZmln L2lmY29uZmlnLjgKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc2Jpbi9pZmNvbmZpZy9pZmNvbmZpZy44 CShyZXZpc2lvbiAyMDMwMjEpCisrKyBzYmluL2lmY29uZmlnL2lmY29uZmlnLjgJKHdvcmtp bmcgY29weSkKQEAgLTI4LDcgKzI4LDcgQEAKIC5cIiAgICAgRnJvbTogQCgjKWlmY29uZmln LjgJOC4zIChCZXJrZWxleSkgMS81Lzk0CiAuXCIgJEZyZWVCU0QkCiAuXCIKLS5EZCBTZXB0 ZW1iZXIgMjMsIDIwMDkKKy5EZCBKYW51YXJ5IDI2LCAyMDEwCiAuRHQgSUZDT05GSUcgOAog Lk9zCiAuU2ggTkFNRQpAQCAtMjU4LDYgKzI1OCwxMiBAQCBEaXNhYmxlIHBlcm1hbmVudGx5 IHByb21pc2N1b3VzIG1vZGUuCiBBbm90aGVyIG5hbWUgZm9yIHRoZQogLkZsIGFsaWFzCiBw YXJhbWV0ZXIuCisuSXQgQ20gZGVzY3JpcHRpb24gQXIgdmFsdWUgLCBDbSBkZXNjciBBciB2 YWx1ZQorU3BlY2lmeSBhIGRlc2NyaXB0aW9uIG9mIHRoZSBpbnRlcmZhY2UuCitUaGlzIGNh biBiZSB1c2VkIHRvIGxhYmVsIGludGVyZmFjZXMgaW4gc2l0dWF0aW9ucyB3aGVyZSB0aGV5 IG1heQorb3RoZXJ3aXNlIGJlIGRpZmZpY3VsdCB0byBkaXN0aW5ndWlzaC4KKy5JdCBDbSAt ZGVzY3JpcHRpb24gLCBDbSAtZGVzY3IKK0NsZWFyIHRoZSBpbnRlcmZhY2UgZGVzY3JpcHRp b24uCiAuSXQgQ20gZG93bgogTWFyayBhbiBpbnRlcmZhY2UKIC5EcSBkb3duIC4KQEAgLTI1 MTIsNiArMjUxOCwxMCBAQCBDb25maWd1cmUgdGhlIGludGVyZmFjZQogdG8gdXNlIDEwMGJh c2VUWCwgZnVsbCBkdXBsZXggRXRoZXJuZXQgbWVkaWEgb3B0aW9uczoKIC5EbCAjIGlmY29u ZmlnIHhsMCBtZWRpYSAxMDBiYXNlVFggbWVkaWFvcHQgZnVsbC1kdXBsZXgKIC5QcAorTGFi ZWwgdGhlIGVtMCBpbnRlcmZhY2UgYXMgYW4gdXBsaW5rOgorLlBwCisuRGwgIyBpZmNvbmZp ZyBlbTAgZGVzY3JpcHRpb24gXCYiVXBsaW5rIHRvIEdpZ2FiaXQgU3dpdGNoIDJcJiIKKy5Q cAogQ3JlYXRlIHRoZSBzb2Z0d2FyZSBuZXR3b3JrIGludGVyZmFjZQogLkxpIGdpZjEgOgog LkRsICMgaWZjb25maWcgZ2lmMSBjcmVhdGUKSW5kZXg6IHNiaW4vaWZjb25maWcvaWZjb25m aWcuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09Ci0tLSBzYmluL2lmY29uZmlnL2lmY29uZmlnLmMJKHJldmlz aW9uIDIwMzAyMSkKKysrIHNiaW4vaWZjb25maWcvaWZjb25maWcuYwkod29ya2luZyBjb3B5 KQpAQCAtNDQsNyArNDQsNiBAQCBzdGF0aWMgY29uc3QgY2hhciByY3NpZFtdID0KICNpbmNs dWRlIDxzeXMvcGFyYW0uaD4KICNpbmNsdWRlIDxzeXMvaW9jdGwuaD4KICNpbmNsdWRlIDxz eXMvc29ja2V0Lmg+Ci0jaW5jbHVkZSA8c3lzL3N5c2N0bC5oPgogI2luY2x1ZGUgPHN5cy90 aW1lLmg+CiAjaW5jbHVkZSA8c3lzL21vZHVsZS5oPgogI2luY2x1ZGUgPHN5cy9saW5rZXIu aD4KQEAgLTgzLDYgKzgyLDggQEAgc3RhdGljIGNvbnN0IGNoYXIgcmNzaWRbXSA9CiBzdHJ1 Y3QJaWZyZXEgaWZyOwogCiBjaGFyCW5hbWVbSUZOQU1TSVpdOworY2hhcgkqZGVzY3IgPSBO VUxMOworc2l6ZV90CWRlc2NybGVuID0gNjQ7CiBpbnQJc2V0YWRkcjsKIGludAlzZXRtYXNr OwogaW50CWRvYWxpYXM7CkBAIC04MzgsNiArODM5LDQwIEBAIHNldGlmbmFtZShjb25zdCBj aGFyICp2YWwsIGludCBkdW1teSBfX3VudXNlZCwgaW50CiAJZnJlZShuZXduYW1lKTsKIH0K IAorLyogQVJHU1VTRUQgKi8KK3N0YXRpYyB2b2lkCitzZXRpZmRlc2NyKGNvbnN0IGNoYXIg KnZhbCwgaW50IGR1bW15IF9fdW51c2VkLCBpbnQgcywgCisgICAgY29uc3Qgc3RydWN0IGFm c3d0Y2ggKmFmcCkKK3sKKwljaGFyICpuZXdkZXNjcjsKKworCWlmci5pZnJfYnVmZmVyLmxl bmd0aCA9IHN0cmxlbih2YWwpICsgMTsKKwlpZiAoaWZyLmlmcl9idWZmZXIubGVuZ3RoID09 IDEpIHsKKwkJaWZyLmlmcl9idWZmZXIuYnVmZmVyID0gbmV3ZGVzY3IgPSBOVUxMOworCQlp ZnIuaWZyX2J1ZmZlci5sZW5ndGggPSAwOworCX0gZWxzZSB7CisJCW5ld2Rlc2NyID0gc3Ry ZHVwKHZhbCk7CisJCWlmci5pZnJfYnVmZmVyLmJ1ZmZlciA9IG5ld2Rlc2NyOworCQlpZiAo bmV3ZGVzY3IgPT0gTlVMTCkgeworCQkJd2Fybigibm8gbWVtb3J5IHRvIHNldCBpZmRlc2Ny Iik7CisJCQlyZXR1cm47CisJCX0KKwl9CisKKwlpZiAoaW9jdGwocywgU0lPQ1NJRkRFU0NS LCAoY2FkZHJfdCkmaWZyKSA8IDApCisJCXdhcm4oImlvY3RsIChzZXQgZGVzY3IpIik7CisK KwlmcmVlKG5ld2Rlc2NyKTsKK30KKworLyogQVJHU1VTRUQgKi8KK3N0YXRpYyB2b2lkCit1 bnNldGlmZGVzY3IoY29uc3QgY2hhciAqdmFsLCBpbnQgdmFsdWUsIGludCBzLCBjb25zdCBz dHJ1Y3QgYWZzd3RjaCAqYWZwKQoreworCisJc2V0aWZkZXNjcigiIiwgMCwgcywgMCk7Cit9 CisKICNkZWZpbmUJSUZGQklUUyBcCiAiXDAyMFwxVVBcMkJST0FEQ0FTVFwzREVCVUdcNExP T1BCQUNLXDVQT0lOVE9QT0lOVFw2U01BUlRcN1JVTk5JTkciIFwKICJcMTBOT0FSUFwxMVBS T01JU0NcMTJBTExNVUxUSVwxM09BQ1RJVkVcMTRTSU1QTEVYXDE1TElOSzBcMTZMSU5LMVwx N0xJTksyIiBcCkBAIC04ODIsNiArOTE3LDI1IEBAIHN0YXR1cyhjb25zdCBzdHJ1Y3QgYWZz d3RjaCAqYWZwLCBjb25zdCBzdHJ1Y3Qgc29jCiAJCXByaW50ZigiIG10dSAlZCIsIGlmci5p ZnJfbXR1KTsKIAlwdXRjaGFyKCdcbicpOwogCisJZm9yICg7OykgeworCQlpZiAoKGRlc2Ny ID0gcmVhbGxvY2YoZGVzY3IsIGRlc2NybGVuKSkgIT0gTlVMTCkgeworCQkJaWZyLmlmcl9i dWZmZXIuYnVmZmVyID0gZGVzY3I7CisJCQlpZnIuaWZyX2J1ZmZlci5sZW5ndGggPSBkZXNj cmxlbjsKKwkJCWlmIChpb2N0bChzLCBTSU9DR0lGREVTQ1IsICZpZnIpID09IDApIHsKKwkJ CQlpZiAoc3RybGVuKGRlc2NyKSA+IDApCisJCQkJCXByaW50ZigiXHRkZXNjcmlwdGlvbjog JXNcbiIsIGRlc2NyKTsKKwkJCQlicmVhazsKKwkJCX0gZWxzZSBpZiAoZXJybm8gPT0gRU5B TUVUT09MT05HKQorCQkJCWRlc2NybGVuID0gaWZyLmlmcl9idWZmZXIubGVuZ3RoOworCQkJ ZWxzZQorCQkJCWJyZWFrOworCQl9IGVsc2UgeworCQkJd2FybigidW5hYmxlIHRvIGFsbG9j YXRlIG1lbW9yeSBmb3IgaW50ZXJmYWNlIgorCQkJICAgICJkZXNjcmlwdGlvbiIpOworCQkJ YnJlYWs7CisJCX0KKwl9OworCiAJaWYgKGlvY3RsKHMsIFNJT0NHSUZDQVAsIChjYWRkcl90 KSZpZnIpID09IDApIHsKIAkJaWYgKGlmci5pZnJfY3VyY2FwICE9IDApIHsKIAkJCXByaW50 YigiXHRvcHRpb25zIiwgaWZyLmlmcl9jdXJjYXAsIElGQ0FQQklUUyk7CkBAIC0xMDUxLDYg KzExMDUsMTAgQEAgc3RhdGljIHN0cnVjdCBjbWQgYmFzaWNfY21kc1tdID0gewogCURFRl9D TUQoIi1hcnAiLAkJSUZGX05PQVJQLAlzZXRpZmZsYWdzKSwKIAlERUZfQ01EKCJkZWJ1ZyIs CUlGRl9ERUJVRywJc2V0aWZmbGFncyksCiAJREVGX0NNRCgiLWRlYnVnIiwJLUlGRl9ERUJV RywJc2V0aWZmbGFncyksCisJREVGX0NNRF9BUkcoImRlc2NyaXB0aW9uIiwJCXNldGlmZGVz Y3IpLAorCURFRl9DTURfQVJHKCJkZXNjciIsCQkJc2V0aWZkZXNjciksCisJREVGX0NNRCgi LWRlc2NyaXB0aW9uIiwJMCwJCXVuc2V0aWZkZXNjciksCisJREVGX0NNRCgiLWRlc2NyIiwJ MCwJCXVuc2V0aWZkZXNjciksCiAJREVGX0NNRCgicHJvbWlzYyIsCUlGRl9QUFJPTUlTQywJ c2V0aWZmbGFncyksCiAJREVGX0NNRCgiLXByb21pc2MiLAktSUZGX1BQUk9NSVNDLAlzZXRp ZmZsYWdzKSwKIAlERUZfQ01EKCJhZGQiLAkJSUZGX1VQLAkJbm90ZWFsaWFzKSwKSW5kZXg6 IHNoYXJlL21hbi9tYW40L25ldGludHJvLjQKPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc2hhcmUvbWFu L21hbjQvbmV0aW50cm8uNAkocmV2aXNpb24gMjAzMDIxKQorKysgc2hhcmUvbWFuL21hbjQv bmV0aW50cm8uNAkod29ya2luZyBjb3B5KQpAQCAtMzIsNyArMzIsNyBAQAogLlwiICAgICBA KCMpbmV0aW50cm8uNAk4LjIgKEJlcmtlbGV5KSAxMS8zMC85MwogLlwiICRGcmVlQlNEJAog LlwiCi0uRGQgSnVuZSAxOCwgMjAwNAorLkRkIEphbnVhcnkgMjYsIDIwMTAKIC5EdCBORVRJ TlRSTyA0CiAuT3MKIC5TaCBOQU1FCkBAIC0yMDQsNiArMjA0LDcgQEAgc3RydWN0CWlmcmVx IHsKICAgICAgICAgc3RydWN0ICAgIHNvY2thZGRyIGlmcnVfYWRkcjsKICAgICAgICAgc3Ry dWN0ICAgIHNvY2thZGRyIGlmcnVfZHN0YWRkcjsKICAgICAgICAgc3RydWN0ICAgIHNvY2th ZGRyIGlmcnVfYnJvYWRhZGRyOworICAgICAgICBzdHJ1Y3QgICAgaWZyZXFfYnVmZmVyIGlm cnVfYnVmZmVyOwogICAgICAgICBzaG9ydCAgICAgaWZydV9mbGFnc1syXTsKICAgICAgICAg c2hvcnQgICAgIGlmcnVfaW5kZXg7CiAgICAgICAgIGludCAgICAgICBpZnJ1X21ldHJpYzsK QEAgLTIxNiw2ICsyMTcsNyBAQCBzdHJ1Y3QJaWZyZXEgewogI2RlZmluZSBpZnJfYWRkciAg ICAgIGlmcl9pZnJ1LmlmcnVfYWRkciAgICAgIC8qIGFkZHJlc3MgKi8KICNkZWZpbmUgaWZy X2RzdGFkZHIgICBpZnJfaWZydS5pZnJ1X2RzdGFkZHIgICAvKiBvdGhlciBlbmQgb2YgcC10 by1wIGxpbmsgKi8KICNkZWZpbmUgaWZyX2Jyb2FkYWRkciBpZnJfaWZydS5pZnJ1X2Jyb2Fk YWRkciAvKiBicm9hZGNhc3QgYWRkcmVzcyAqLworI2RlZmluZSBpZnJfYnVmZmVyICAgIGlm cl9pZnJ1LmlmcnVfYnVmZmVyICAgIC8qIHVzZXIgc3VwcGxpZWQgYnVmZmVyIHdpdGggaXRz IGxlbmd0aCAqLwogI2RlZmluZSBpZnJfZmxhZ3MgICAgIGlmcl9pZnJ1LmlmcnVfZmxhZ3Nb MF0gIC8qIGZsYWdzIChsb3cgMTYgYml0cykgKi8KICNkZWZpbmUgaWZyX2ZsYWdzaGlnaCBp ZnJfaWZydS5pZnJ1X2ZsYWdzWzFdICAvKiBmbGFncyAoaGlnaCAxNiBiaXRzKSAqLwogI2Rl ZmluZSBpZnJfbWV0cmljICAgIGlmcl9pZnJ1LmlmcnVfbWV0cmljICAgIC8qIG1ldHJpYyAq LwpAQCAtMjc3LDYgKzI3OSwzMiBAQCBhbmQKIGZpZWxkcyBvZiB0aGUKIC5WdCBpZnJlcQog c3RydWN0dXJlLCByZXNwZWN0aXZlbHkuCisuSXQgRHYgU0lPQ0dJRkRFU0NSCitHZXQgdGhl IGludGVyZmFjZSBkZXNjcmlwdGlvbiwgcmV0dXJuZWQgaW4gdGhlCisuVmEgYnVmZmVyCitm aWVsZCBvZgorLlZhIGlmcnVfYnVmZmVyCitzdHJ1Y3QuCitUaGUgdXNlciBzdXBwbGllZCBi dWZmZXIgbGVuZ3RoIHNob3VsZCBiZSBkZWZpbmVkIGluIHRoZQorLlZhIGxlbmd0aAorZmll bGQgb2YKKy5WYSBpZnJ1X2J1ZmZlcgorc3RydWN0IHBhc3NlZCBpbiBhcyBwYXJhbWV0ZXIs IGFuZCB0aGUgbGVuZ3RoIHdvdWxkIGluY2x1ZGUKK3RoZSB0ZXJtaW5hdGluZyBudWwgY2hh cmFjdGVyLiAgSWYgdGhlcmUgaXMgbm90IGVub3VnaCBzcGFjZQordG8gaG9sZCB0aGUgaW50 ZXJmYWNlIGxlbmd0aCwgbm8gY29weSB3b3VsZCBiZSBkb25lIGFuZCBhbgorZXJyb3Igd291 bGQgYmUgcmV0dXJuZWQuICBUaGUga2VybmVsIHdpbGwgc3RvcmUgdGhlIGJ1ZmZlcgorbGVu Z3RoIGluIHRoZQorLlZhIGxlbmd0aAorZmllbGQgdXBvbiByZXR1cm4sIHJlZ2FyZGxlc3Mg d2hldGhlciB0aGUgYnVmZmVyIGl0c2VsZiBpcworc3VmZmljaWVudCB0byBob2xkIHRoZSBk YXRhLgorLkl0IER2IFNJT0NTSUZERVNDUgorU2V0IHRoZSBpbnRlcmZhY2UgZGVzY3JpcHRp b24gdG8gdGhlIHZhbHVlIG9mIHRoZQorLlZhIGJ1ZmZlcgorZmllbGQgb2YKKy5WYSBpZnJ1 X2J1ZmZlcgorc3RydWN0LCB3aXRoCisuVmEgbGVuZ3RoCitmaWVsZCBzcGVjaWZ5aW5nIGl0 cyBsZW5ndGggKGNvdW50aW5nIHRoZSB0ZXJtaW5hdGluZyBudWwpLgogLkl0IER2IFNJT0NT SUZGTEFHUwogU2V0IGludGVyZmFjZSBmbGFncyBmaWVsZC4KIElmIHRoZSBpbnRlcmZhY2Ug aXMgbWFya2VkIGRvd24sCkBAIC00MDQsNiArNDMyLDEzIEBAIHN0cnVjdCBpZl9jbG9uZXJl cSB7CiAgICAgICAgIGNoYXIgICAgKmlmY3JfYnVmZmVyOyAgIC8qIGJ1ZmZlciBmb3IgY2xv bmVyIG5hbWVzICovCiB9OwogLkVkCisuQmQgLWxpdGVyYWwKKy8qIFN0cnVjdHVyZSB1c2Vk IGluIFNJT0NHSUZERVNDUiBhbmQgU0lPQ1NJRkRFU0NSIHJlcXVlc3RzICovCitzdHJ1Y3Qg aWZyZXFfYnVmZmVyIHsKKyAgICAgICAgc2l6ZV90ICBsZW5ndGg7ICAgICAgICAgLyogbGVu Z3RoIG9mIHRoZSBidWZmZXIgKi8KKyAgICAgICAgdm9pZCAgICpidWZmZXI7ICAgICAgICAg LyogcG9pbnRlciB0byB1c2VybGFuZCBzcGFjZSBidWZmZXIgKi8KK307CisuRWQKIC5TaCBT RUUgQUxTTwogLlhyIGlvY3RsIDIgLAogLlhyIHNvY2tldCAyICwKSW5kZXg6IHN5cy9rZXJu L2tlcm5famFpbC5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9rZXJuL2tlcm5famFpbC5jCShy ZXZpc2lvbiAyMDMwMjEpCisrKyBzeXMva2Vybi9rZXJuX2phaWwuYwkod29ya2luZyBjb3B5 KQpAQCAtMzU5Miw2ICszNTkyLDcgQEAgcHJpc29uX3ByaXZfY2hlY2soc3RydWN0IHVjcmVk ICpjcmVkLCBpbnQgcHJpdikKIAljYXNlIFBSSVZfTkVUX1NFVElGTVRVOgogCWNhc2UgUFJJ Vl9ORVRfU0VUSUZGTEFHUzoKIAljYXNlIFBSSVZfTkVUX1NFVElGQ0FQOgorCWNhc2UgUFJJ Vl9ORVRfU0VUSUZERVNDUjoKIAljYXNlIFBSSVZfTkVUX1NFVElGTkFNRQk6CiAJY2FzZSBQ UklWX05FVF9TRVRJRk1FVFJJQzoKIAljYXNlIFBSSVZfTkVUX1NFVElGUEhZUzoKSW5kZXg6 IHN5cy9uZXQvaWYuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvbmV0L2lmLmMJKHJldmlzaW9u IDIwMzAyMSkKKysrIHN5cy9uZXQvaWYuYwkod29ya2luZyBjb3B5KQpAQCAtMTA2LDYgKzEw NiwxOCBAQCBTWVNDVExfSU5UKF9uZXRfbGluaywgT0lEX0FVVE8sIGxvZ19saW5rX3N0YXRl X2NoYQogCSZsb2dfbGlua19zdGF0ZV9jaGFuZ2UsIDAsCiAJImxvZyBpbnRlcmZhY2UgbGlu ayBzdGF0ZSBjaGFuZ2UgZXZlbnRzIik7CiAKKy8qIEludGVyZmFjZSBkZXNjcmlwdGlvbiAq Lworc3RhdGljIHVuc2lnbmVkIGludCBpZmRlc2NyX21heGxlbiA9IDEwMjQ7CitTWVNDVExf VUlOVChfbmV0LCBPSURfQVVUTywgaWZkZXNjcl9tYXhsZW4sIENUTEZMQUdfUlcsCisJJmlm ZGVzY3JfbWF4bGVuLCAwLAorCSJhZG1pbmlzdHJhdGl2ZSBtYXhpbXVtIGxlbmd0aCBmb3Ig aW50ZXJmYWNlIGRlc2NyaXB0aW9uIik7CisKK01BTExPQ19ERUZJTkUoTV9JRkRFU0NSLCAi aWZkZXNjciIsICJpZm5ldCBkZXNjcmlwdGlvbnMiKTsKKworLyogZ2xvYmFsIHN4IGZvciBu b24tY3JpdGljYWwgcGF0aCBpZmRlc2NyICovCitzdGF0aWMgc3RydWN0IHN4IGlmZGVzY3Jf c3g7CitTWF9TWVNJTklUKGlmZGVzY3Jfc3gsICZpZmRlc2NyX3N4LCAiaWZuZXQgZGVzY3Ii KTsKKwogdm9pZAkoKmJzdHBfbGlua3N0YXRlX3ApKHN0cnVjdCBpZm5ldCAqaWZwLCBpbnQg c3RhdGUpOwogdm9pZAkoKm5nX2V0aGVyX2xpbmtfc3RhdGVfcCkoc3RydWN0IGlmbmV0ICpp ZnAsIGludCBzdGF0ZSk7CiB2b2lkCSgqbGFnZ19saW5rc3RhdGVfcCkoc3RydWN0IGlmbmV0 ICppZnAsIGludCBzdGF0ZSk7CkBAIC00NDIsNiArNDU0LDggQEAgaWZfZnJlZV9pbnRlcm5h bChzdHJ1Y3QgaWZuZXQgKmlmcCkKICNpZmRlZiBNQUMKIAltYWNfaWZuZXRfZGVzdHJveShp ZnApOwogI2VuZGlmIC8qIE1BQyAqLworCWlmIChpZnAtPmlmX2Rlc2NyaXB0aW9uICE9IE5V TEwpCisJCWZyZWUoaWZwLT5pZl9kZXNjcmlwdGlvbiwgTV9JRkRFU0NSKTsKIAlJRl9BRkRB VEFfREVTVFJPWShpZnApOwogCUlGX0FERFJfTE9DS19ERVNUUk9ZKGlmcCk7CiAJaWZxX2Rl bGV0ZSgmaWZwLT5pZl9zbmQpOwpAQCAtMTk3OSw2ICsxOTkzLDggQEAgaWZod2lvY3RsKHVf bG9uZyBjbWQsIHN0cnVjdCBpZm5ldCAqaWZwLCBjYWRkcl90IGQKIAlpbnQgZXJyb3IgPSAw OwogCWludCBuZXdfZmxhZ3MsIHRlbXBfZmxhZ3M7CiAJc2l6ZV90IG5hbWVsZW4sIG9uYW1l bGVuOworCXNpemVfdCBkZXNjcmxlbjsKKwljaGFyICpkZXNjcmJ1ZiwgKm9kZXNjcmJ1ZjsK IAljaGFyIG5ld19uYW1lW0lGTkFNU0laXTsKIAlzdHJ1Y3QgaWZhZGRyICppZmE7CiAJc3Ry dWN0IHNvY2thZGRyX2RsICpzZGw7CkBAIC0yMDE4LDYgKzIwMzQsNjAgQEAgaWZod2lvY3Rs KHVfbG9uZyBjbWQsIHN0cnVjdCBpZm5ldCAqaWZwLCBjYWRkcl90IGQKIAkJaWZyLT5pZnJf cGh5cyA9IGlmcC0+aWZfcGh5c2ljYWw7CiAJCWJyZWFrOwogCisJY2FzZSBTSU9DR0lGREVT Q1I6CisJCWVycm9yID0gMDsKKwkJc3hfc2xvY2soJmlmZGVzY3Jfc3gpOworCQlpZiAoaWZw LT5pZl9kZXNjcmlwdGlvbiA9PSBOVUxMKSB7CisJCQlpZnItPmlmcl9idWZmZXIubGVuZ3Ro ID0gMDsKKwkJCWVycm9yID0gRU5PTVNHOworCQl9IGVsc2UgeworCQkJLyogc3BhY2UgZm9y IHRlcm1pbmF0aW5nIG51bCAqLworCQkJZGVzY3JsZW4gPSBzdHJsZW4oaWZwLT5pZl9kZXNj cmlwdGlvbikgKyAxOworCQkJaWYgKGlmci0+aWZyX2J1ZmZlci5sZW5ndGggPCBkZXNjcmxl bikKKwkJCQllcnJvciA9IEVOQU1FVE9PTE9ORzsKKwkJCWVsc2UKKwkJCQllcnJvciA9IGNv cHlvdXQoaWZwLT5pZl9kZXNjcmlwdGlvbiwKKwkJCQkgICAgaWZyLT5pZnJfYnVmZmVyLmJ1 ZmZlciwgZGVzY3JsZW4pOworCQkJaWZyLT5pZnJfYnVmZmVyLmxlbmd0aCA9IGRlc2NybGVu OworCQl9CisJCXN4X3N1bmxvY2soJmlmZGVzY3Jfc3gpOworCQlicmVhazsKKworCWNhc2Ug U0lPQ1NJRkRFU0NSOgorCQllcnJvciA9IHByaXZfY2hlY2sodGQsIFBSSVZfTkVUX1NFVElG REVTQ1IpOworCQlpZiAoZXJyb3IpCisJCQlyZXR1cm4gKGVycm9yKTsKKworCQkvKgorCQkg KiBDb3B5IG9ubHkgKGxlbmd0aC0xKSBieXRlcyB0byBtYWtlIHN1cmUgdGhhdAorCQkgKiBp Zl9kZXNjcmlwdGlvbiBpcyBhbHdheXMgbnVsIHRlcm1pbmF0ZWQuICBUaGUKKwkJICogbGVu Z3RoIHBhcmFtZXRlciBpcyBzdXBwb3NlZCB0byBjb3VudCB0aGUKKwkJICogdGVybWluYXRp bmcgbnVsIGluLgorCQkgKi8KKwkJaWYgKGlmci0+aWZyX2J1ZmZlci5sZW5ndGggPiBpZmRl c2NyX21heGxlbikKKwkJCXJldHVybiAoRU5BTUVUT09MT05HKTsKKwkJZWxzZSBpZiAoaWZy LT5pZnJfYnVmZmVyLmxlbmd0aCA9PSAwKQorCQkJZGVzY3JidWYgPSBOVUxMOworCQllbHNl IHsKKwkJCWRlc2NyYnVmID0gbWFsbG9jKGlmci0+aWZyX2J1ZmZlci5sZW5ndGgsIE1fSUZE RVNDUiwKKwkJCSAgICBNX1dBSVRPSyB8IE1fWkVSTyk7CisJCQllcnJvciA9IGNvcHlpbihp ZnItPmlmcl9idWZmZXIuYnVmZmVyLCBkZXNjcmJ1ZiwKKwkJCSAgICBpZnItPmlmcl9idWZm ZXIubGVuZ3RoIC0gMSk7CisJCQlpZiAoZXJyb3IpIHsKKwkJCQlmcmVlKGRlc2NyYnVmLCBN X0lGREVTQ1IpOworCQkJCWJyZWFrOworCQkJfQorCQl9CisKKwkJc3hfeGxvY2soJmlmZGVz Y3Jfc3gpOworCQlvZGVzY3JidWYgPSBpZnAtPmlmX2Rlc2NyaXB0aW9uOworCQlpZnAtPmlm X2Rlc2NyaXB0aW9uID0gZGVzY3JidWY7CisJCXN4X3h1bmxvY2soJmlmZGVzY3Jfc3gpOwor CisJCWdldG1pY3JvdGltZSgmaWZwLT5pZl9sYXN0Y2hhbmdlKTsKKwkJZnJlZShvZGVzY3Ji dWYsIE1fSUZERVNDUik7CisJCWJyZWFrOworCiAJY2FzZSBTSU9DU0lGRkxBR1M6CiAJCWVy cm9yID0gcHJpdl9jaGVjayh0ZCwgUFJJVl9ORVRfU0VUSUZGTEFHUyk7CiAJCWlmIChlcnJv cikKSW5kZXg6IHN5cy9uZXQvaWYuaAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvbmV0L2lmLmgJ KHJldmlzaW9uIDIwMzAyMSkKKysrIHN5cy9uZXQvaWYuaAkod29ya2luZyBjb3B5KQpAQCAt Mjg0LDYgKzI4NCwxNCBAQCBzdHJ1Y3QgaWZfYW5ub3VuY2Vtc2doZHIgewogI2RlZmluZQlJ RkFOX0RFUEFSVFVSRQkxCS8qIGludGVyZmFjZSBkZXBhcnR1cmUgKi8KIAogLyoKKyAqIEJ1 ZmZlciB3aXRoIGxlbmd0aCB0byBiZSB1c2VkIGluIFNJT0NHSUZERVNDUi9TSU9DU0lGREVT Q1IgcmVxdWVzdHMKKyAqLworc3RydWN0IGlmcmVxX2J1ZmZlciB7CisJc2l6ZV90CWxlbmd0 aDsKKwl2b2lkCSpidWZmZXI7Cit9OworCisvKgogICogSW50ZXJmYWNlIHJlcXVlc3Qgc3Ry dWN0dXJlIHVzZWQgZm9yIHNvY2tldAogICogaW9jdGwncy4gIEFsbCBpbnRlcmZhY2UgaW9j dGwncyBtdXN0IGhhdmUgcGFyYW1ldGVyCiAgKiBkZWZpbml0aW9ucyB3aGljaCBiZWdpbiB3 aXRoIGlmcl9uYW1lLiAgVGhlCkBAIC0yOTUsNiArMzAzLDcgQEAgc3RydWN0CWlmcmVxIHsK IAkJc3RydWN0CXNvY2thZGRyIGlmcnVfYWRkcjsKIAkJc3RydWN0CXNvY2thZGRyIGlmcnVf ZHN0YWRkcjsKIAkJc3RydWN0CXNvY2thZGRyIGlmcnVfYnJvYWRhZGRyOworCQlzdHJ1Y3QJ aWZyZXFfYnVmZmVyIGlmcnVfYnVmZmVyOwogCQlzaG9ydAlpZnJ1X2ZsYWdzWzJdOwogCQlz aG9ydAlpZnJ1X2luZGV4OwogCQlpbnQJaWZydV9qaWQ7CkBAIC0zMDgsNiArMzE3LDcgQEAg c3RydWN0CWlmcmVxIHsKICNkZWZpbmUJaWZyX2FkZHIJaWZyX2lmcnUuaWZydV9hZGRyCS8q IGFkZHJlc3MgKi8KICNkZWZpbmUJaWZyX2RzdGFkZHIJaWZyX2lmcnUuaWZydV9kc3RhZGRy CS8qIG90aGVyIGVuZCBvZiBwLXRvLXAgbGluayAqLwogI2RlZmluZQlpZnJfYnJvYWRhZGRy CWlmcl9pZnJ1LmlmcnVfYnJvYWRhZGRyCS8qIGJyb2FkY2FzdCBhZGRyZXNzICovCisjZGVm aW5lCWlmcl9idWZmZXIJaWZyX2lmcnUuaWZydV9idWZmZXIJLyogdXNlciBzdXBwbGllZCBi dWZmZXIgd2l0aCBpdHMgbGVuZ3RoICovCiAjZGVmaW5lCWlmcl9mbGFncwlpZnJfaWZydS5p ZnJ1X2ZsYWdzWzBdCS8qIGZsYWdzIChsb3cgMTYgYml0cykgKi8KICNkZWZpbmUJaWZyX2Zs YWdzaGlnaAlpZnJfaWZydS5pZnJ1X2ZsYWdzWzFdCS8qIGZsYWdzIChoaWdoIDE2IGJpdHMp ICovCiAjZGVmaW5lCWlmcl9qaWQJCWlmcl9pZnJ1LmlmcnVfamlkCS8qIGphaWwvdm5ldCAq LwpJbmRleDogc3lzL25ldC9pZl92YXIuaAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvbmV0L2lm X3Zhci5oCShyZXZpc2lvbiAyMDMwMjEpCisrKyBzeXMvbmV0L2lmX3Zhci5oCSh3b3JraW5n IGNvcHkpCkBAIC0yMDMsNyArMjAzLDggQEAgc3RydWN0IGlmbmV0IHsKIAkgKiBiZSB1c2Vk IHdpdGggY2FyZSB3aGVyZSBiaW5hcnkgY29tcGF0aWJpbGl0eSBpcyByZXF1aXJlZC4KIAkg Ki8KIAljaGFyCSBpZl9jc3BhcmVbM107Ci0Jdm9pZAkqaWZfcHNwYXJlWzhdOworCWNoYXIJ KmlmX2Rlc2NyaXB0aW9uOwkvKiBpbnRlcmZhY2UgZGVzY3JpcHRpb24gKi8KKwl2b2lkCSpp Zl9wc3BhcmVbN107CiAJaW50CWlmX2lzcGFyZVs0XTsKIH07CiAKSW5kZXg6IHN5cy9zeXMv cGFyYW0uaAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvc3lzL3BhcmFtLmgJKHJldmlzaW9uIDIw MzAyMSkKKysrIHN5cy9zeXMvcGFyYW0uaAkod29ya2luZyBjb3B5KQpAQCAtNTgsNyArNTgs NyBAQAogICoJCWluIHRoZSByYW5nZSA1IHRvIDkuCiAgKi8KICN1bmRlZiBfX0ZyZWVCU0Rf dmVyc2lvbgotI2RlZmluZSBfX0ZyZWVCU0RfdmVyc2lvbiA5MDAwMDgJLyogTWFzdGVyLCBw cm9wYWdhdGVkIHRvIG5ld3ZlcnMgKi8KKyNkZWZpbmUgX19GcmVlQlNEX3ZlcnNpb24gOTAw MDA5CS8qIE1hc3RlciwgcHJvcGFnYXRlZCB0byBuZXd2ZXJzICovCiAKICNpZm5kZWYgTE9D T1JFCiAjaW5jbHVkZSA8c3lzL3R5cGVzLmg+CkluZGV4OiBzeXMvc3lzL3ByaXYuaAo9PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09Ci0tLSBzeXMvc3lzL3ByaXYuaAkocmV2aXNpb24gMjAzMDIxKQorKysgc3lz L3N5cy9wcml2LmgJKHdvcmtpbmcgY29weSkKQEAgLTMzNSw2ICszMzUsNyBAQAogI2RlZmlu ZQlQUklWX05FVF9MQUdHCQk0MTUJLyogQWRtaW5pc3RlciBsYWdnIGludGVyZmFjZS4gKi8K ICNkZWZpbmUJUFJJVl9ORVRfR0lGCQk0MTYJLyogQWRtaW5pc3RlciBnaWYgaW50ZXJmYWNl LiAqLwogI2RlZmluZQlQUklWX05FVF9TRVRJRlZORVQJNDE3CS8qIE1vdmUgaW50ZXJmYWNl IHRvIHZuZXQuICovCisjZGVmaW5lCVBSSVZfTkVUX1NFVElGREVTQ1IJNDE4CS8qIFNldCBp bnRlcmZhY2UgZGVzY3JpcHRpb24uICovCiAKIC8qCiAgKiA4MDIuMTEtcmVsYXRlZCBwcml2 aWxlZ2VzLgpJbmRleDogc3lzL3N5cy9zb2NraW8uaAo9PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMv c3lzL3NvY2tpby5oCShyZXZpc2lvbiAyMDMwMjEpCisrKyBzeXMvc3lzL3NvY2tpby5oCSh3 b3JraW5nIGNvcHkpCkBAIC04Miw2ICs4Miw4IEBACiAjZGVmaW5lCVNJT0NHSUZNQUMJX0lP V1IoJ2knLCAzOCwgc3RydWN0IGlmcmVxKQkvKiBnZXQgSUYgTUFDIGxhYmVsICovCiAjZGVm aW5lCVNJT0NTSUZNQUMJIF9JT1coJ2knLCAzOSwgc3RydWN0IGlmcmVxKQkvKiBzZXQgSUYg TUFDIGxhYmVsICovCiAjZGVmaW5lCVNJT0NTSUZOQU1FCSBfSU9XKCdpJywgNDAsIHN0cnVj dCBpZnJlcSkJLyogc2V0IElGIG5hbWUgKi8KKyNkZWZpbmUJU0lPQ1NJRkRFU0NSCSBfSU9X KCdpJywgNDEsIHN0cnVjdCBpZnJlcSkJLyogc2V0IGlmbmV0IGRlc2NyICovIAorI2RlZmlu ZQlTSU9DR0lGREVTQ1IJX0lPV1IoJ2knLCA0Miwgc3RydWN0IGlmcmVxKQkvKiBnZXQgaWZu ZXQgZGVzY3IgKi8gCiAKICNkZWZpbmUJU0lPQ0FERE1VTFRJCSBfSU9XKCdpJywgNDksIHN0 cnVjdCBpZnJlcSkJLyogYWRkIG0nY2FzdCBhZGRyICovCiAjZGVmaW5lCVNJT0NERUxNVUxU SQkgX0lPVygnaScsIDUwLCBzdHJ1Y3QgaWZyZXEpCS8qIGRlbCBtJ2Nhc3QgYWRkciAqLwo= --------------010809040603030808010100-- From owner-freebsd-net@FreeBSD.ORG Tue Jan 26 20:52:12 2010 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 E3159106566B; Tue, 26 Jan 2010 20:52:12 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id B34958FC15; Tue, 26 Jan 2010 20:52:12 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 5F31746B38; Tue, 26 Jan 2010 15:52:12 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 9DE5E8A024; Tue, 26 Jan 2010 15:52:11 -0500 (EST) From: John Baldwin To: d@delphij.net Date: Tue, 26 Jan 2010 15:48:21 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20100120; KDE/4.3.1; amd64; ; ) References: <4B5E16DB.2080203@delphij.net> <201001261140.51006.jhb@freebsd.org> <4B5F4ED6.1070400@delphij.net> In-Reply-To: <4B5F4ED6.1070400@delphij.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201001261548.21455.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 26 Jan 2010 15:52:11 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: delphij@freebsd.org, freebsd-net@freebsd.org, Robert Watson Subject: Re: [PATCH] Interface description 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, 26 Jan 2010 20:52:13 -0000 On Tuesday 26 January 2010 3:21:42 pm Xin LI wrote: > On 2010/01/26 08:40, John Baldwin wrote: > > I just have two suggestions/comments: > > @@ -295,6 +295,7 @@ struct ifreq { > [...] > > I prefer to not have this all on one line, but to instead be: > [...] > > Even better would be to actually define a separate type earlier > > in the file I think: > [...] > > I think caddr_t is deprecated in favor of void * for new APIs at least. > > I have split it into another type and used void *, also updated the > manual page. > > > Second, it would be nice if SIOCGIFDESCR provided length feedback to userland > > similar to sysctl(3). Maybe change the code to set ifr.ifr_buffer.length to > > the required length when returning ENAMETOOLONG. Userland can then just skip > > to that length directly, or instead use an idiom similar to sysctl where it > > does the following: > > Done in a slightly different way. It seems to be slightly wasteful (not > a big deal, though) to ioctl every time to obtain the length, so I used > an arbitrary number (2^6) and make the program to adapt to larger number > if kernel gave feedback with ENAMETOOLONG, and the buffer/length would > be used the next call. Ok. My final suggestion is to start each sentence in the manual page on a new line as that is our style for manpages to ease the work of translators. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Wed Jan 27 10:42:02 2010 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 6DE68106566B; Wed, 27 Jan 2010 10:42:02 +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 43DA48FC17; Wed, 27 Jan 2010 10:42:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o0RAg2EG006899; Wed, 27 Jan 2010 10:42:02 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o0RAg25P006895; Wed, 27 Jan 2010 10:42:02 GMT (envelope-from linimon) Date: Wed, 27 Jan 2010 10:42:02 GMT Message-Id: <201001271042.o0RAg25P006895@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/143285: [em] [regression] jumbo frames broken in 8.0 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, 27 Jan 2010 10:42:02 -0000 Synopsis: [em] [regression] jumbo frames broken in 8.0 Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Jan 27 10:41:51 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=143285 From owner-freebsd-net@FreeBSD.ORG Wed Jan 27 12:51:40 2010 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 E50741065670 for ; Wed, 27 Jan 2010 12:51:40 +0000 (UTC) (envelope-from prvs=1643314351=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 7DD498FC0A for ; Wed, 27 Jan 2010 12:51:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=multiplay.co.uk; s=Multiplay; t=1264596039; x=1265200839; q=dns/txt; h=Received: Message-ID:From:To:Subject:Date:MIME-Version:Content-Type: Content-Transfer-Encoding; bh=MzSJ2+pzh09/i9/c1HTpjlsKHtwffKxTM2 rgw1u31Y4=; b=Gtw/WQJA/mWtZCcPTgwfldQP92qyYBHioSfouk7NMbxYj6dWwA Zvdqf7DJty7omYm7CxRpg9ex+ml5BPOifksRT8uDBImPTsvX0SQ8L1kRyc8CIXgC I6bwko9Idh0GteT7JhJQFbwZlDZpDInUeoqot/26llbGF2GxeZsaw4OJE= X-MDAV-Processed: mail1.multiplay.co.uk, Wed, 27 Jan 2010 12:40:39 +0000 Received: from r2d2 by mail1.multiplay.co.uk (MDaemon PRO v10.0.4) with ESMTP id md50009320031.msg for ; Wed, 27 Jan 2010 12:40:38 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Wed, 27 Jan 2010 12:40:38 +0000 (not processed: message from trusted or authenticated source) X-Authenticated-Sender: Killing@multiplay.co.uk X-MDRemoteIP: 213.123.247.160 X-Return-Path: prvs=1643314351=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-net@freebsd.org Message-ID: <8E2B6E11A79B4958B94B44A41C7D4298@multiplay.co.uk> From: "Steven Hartland" To: Date: Wed, 27 Jan 2010 12:40:28 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: Problems getting lagg to balance using lacp 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, 27 Jan 2010 12:51:41 -0000 I've just setup lagg on one of our servers and run some basic tests and although everything seems to be reporting correctly no balancing appears to be happening. The following is the setup: FreeBSD side: ifconfig_em0="up" ifconfig_em1="up" cloned_interfaces="lagg0" ifconfig_lagg0="laggproto lacp laggport em0 laggport em1" ipv4_addrs_lagg0="10.10.1.66/24" Cisco side: interface Port-channel2 description SERVER:: test - lagg0 switchport switchport access vlan 96 switchport mode access no ip address end interface GigabitEthernet3/35 description SERVER:: test - em0 switchport switchport access vlan 96 switchport mode access no ip address channel-protocol lacp channel-group 2 mode active end interface GigabitEthernet3/43 description SERVER:: test - em1 switchport switchport access vlan 96 switchport mode access no ip address channel-protocol lacp channel-group 2 mode active end Config:- em0: flags=8843 metric 0 mtu 1500 options=19b ether 00:30:48:33:ec:44 media: Ethernet autoselect (1000baseT ) status: active em1: flags=8843 metric 0 mtu 1500 options=19b ether 00:30:48:33:ec:44 media: Ethernet autoselect (1000baseT ) status: active lo0: flags=8049 metric 0 mtu 16384 options=3 inet 127.0.0.1 netmask 0xff000000 lagg0: flags=8843 metric 0 mtu 1500 options=19b ether 00:30:48:33:ec:44 inet 10.10.1.66 netmask 0xffffff00 broadcast 10.10.1.255 inet 10.10.1.83 netmask 0xffffffff broadcast 10.10.1.83 media: Ethernet autoselect status: active laggproto lacp laggport: em1 flags=1c laggport: em0 flags=1c show lacp neighbor Flags: S - Device is requesting Slow LACPDUs F - Device is requesting Fast LACPDUs A - Device is in Active mode P - Device is in Passive mode Channel group 2 neighbors Partner's information: Partner Partner LACP Partner Partner Partner Partner Partner Port Flags State Port Priority Admin Key Oper Key Port Number Port State Gi3/35 SA bndl 32768 0x0 0x90 0x1 0x3D Gi3/43 SA bndl 32768 0x0 0x90 0x2 0x3D Stats: Interface Traffic Peak Total lagg0 in 0.351 KB/s 117.349 MB/s 2.695 GB out 0.345 KB/s 114.183 MB/s 8.103 GB em1 in 0.233 KB/s 117.349 MB/s 2.695 GB out 0.000 KB/s 132.535 MB/s 8.890 GB em0 in 0.116 KB/s 2.701 KB/s 331.405 KB out 0.345 KB/s 9.093 KB/s 631.883 KB Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll em0 1500 00:30:48:33:ec:44 5381 0 5188 0 0 em1 1500 00:30:48:33:ec:44 5987608 0 4015584 0 0 lo0 16384 0 0 0 0 0 lo0 16384 your-net localhost 0 - 0 - - lagg0 1500 00:30:48:33:ec:44 5992849 0 4016823 8 0 lagg0 1500 10.10.1.0 test 5985503 - 6475013 - - lagg0 1500 10.10.1.83/ jail1 19 - 0 - - Anyone got any ideas, as far as I can see lacp is negotiating correctly just no balancing is happening :( Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-net@FreeBSD.ORG Wed Jan 27 13:43:57 2010 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 F204D106568D for ; Wed, 27 Jan 2010 13:43:56 +0000 (UTC) (envelope-from shteryana@gmail.com) Received: from mail-ew0-f218.google.com (mail-ew0-f218.google.com [209.85.219.218]) by mx1.freebsd.org (Postfix) with ESMTP id 8078D8FC1E for ; Wed, 27 Jan 2010 13:43:56 +0000 (UTC) Received: by ewy10 with SMTP id 10so1265853ewy.3 for ; Wed, 27 Jan 2010 05:43:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:reply-to:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=TJOQnRwvHegq9xq8r0NU/MM8L2hyfqPKxvNPjqWtkS0=; b=q++zo8AikMlKSthohT6niGDp4kElw37cGQ1hm7qLv9XMUYhEloEwOU5sav/Rl8+Bbi +BKZJ4KmYuv3QEibopBBvpNuu3ecUyx0y9Q+hTzP/+lgNBinSMWfGo+dl34yt8gEPD2U Js5etvxOVFJDAVKIn8EE6E76mrtqN82TLRTxU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:reply-to:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=YhGkWT5+Gv4SkVvcKR1bhJX9Zr6Hex0IbmXIfHEy2Zm6+HHKOws1a9z4rvRCnHzZG0 vhpZMEv5Ut9IM37ebPSlGKMwiabvZ1GPB0VA/HowJTJxIsvRnrEBCHkx2vEN0P5oPF5K l9gn8rpaLJQuMW4P/mQPkjoNoFNV/VCequ5A4= MIME-Version: 1.0 Sender: shteryana@gmail.com Received: by 10.213.48.10 with SMTP id p10mr1322831ebf.18.1264599835000; Wed, 27 Jan 2010 05:43:55 -0800 (PST) In-Reply-To: <8E2B6E11A79B4958B94B44A41C7D4298@multiplay.co.uk> References: <8E2B6E11A79B4958B94B44A41C7D4298@multiplay.co.uk> Date: Wed, 27 Jan 2010 15:43:54 +0200 X-Google-Sender-Auth: a69e11204942f103 Message-ID: <61b573981001270543k6514a5g8d4f679777b69b49@mail.gmail.com> From: Shteryana Shopova To: Steven Hartland Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: Problems getting lagg to balance using lacp X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: syrinx@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 13:43:57 -0000 On Wed, Jan 27, 2010 at 2:40 PM, Steven Hartland wrote: > I've just setup lagg on one of our servers and run some > basic tests and although everything seems to be reporting > correctly no balancing appears to be happening. > > The following is the setup: > > FreeBSD side: > ifconfig_em0=3D"up" > ifconfig_em1=3D"up" > cloned_interfaces=3D"lagg0" > ifconfig_lagg0=3D"laggproto lacp laggport em0 laggport em1" > ipv4_addrs_lagg0=3D"10.10.1.66/24" > > Cisco side: > interface Port-channel2 > description SERVER:: test - lagg0 > switchport > switchport access vlan 96 > switchport mode access > no ip address > end > > interface GigabitEthernet3/35 > description SERVER:: test - em0 > switchport > switchport access vlan 96 > switchport mode access > no ip address > channel-protocol lacp > channel-group 2 mode active > end > > interface GigabitEthernet3/43 > description SERVER:: test - em1 > switchport > switchport access vlan 96 > switchport mode access > no ip address > channel-protocol lacp > channel-group 2 mode active > end > > Config:- > em0: flags=3D8843 metric 0 mtu 15= 00 > =C2=A0 =C2=A0 =C2=A0 options=3D19b > =C2=A0 =C2=A0 =C2=A0 ether 00:30:48:33:ec:44 > =C2=A0 =C2=A0 =C2=A0 media: Ethernet autoselect (1000baseT ) > =C2=A0 =C2=A0 =C2=A0 status: active > em1: flags=3D8843 metric 0 mtu 15= 00 > =C2=A0 =C2=A0 =C2=A0 options=3D19b > =C2=A0 =C2=A0 =C2=A0 ether 00:30:48:33:ec:44 > =C2=A0 =C2=A0 =C2=A0 media: Ethernet autoselect (1000baseT ) > =C2=A0 =C2=A0 =C2=A0 status: active > lo0: flags=3D8049 metric 0 mtu 16384 > =C2=A0 =C2=A0 =C2=A0 options=3D3 > =C2=A0 =C2=A0 =C2=A0 inet 127.0.0.1 netmask 0xff000000 lagg0: > flags=3D8843 metric 0 mtu 1500 > =C2=A0 =C2=A0 =C2=A0 options=3D19b > =C2=A0 =C2=A0 =C2=A0 ether 00:30:48:33:ec:44 > =C2=A0 =C2=A0 =C2=A0 inet 10.10.1.66 netmask 0xffffff00 broadcast 10.10.1= .255 > =C2=A0 =C2=A0 =C2=A0 inet 10.10.1.83 netmask 0xffffffff broadcast 10.10.1= .83 > =C2=A0 =C2=A0 =C2=A0 media: Ethernet autoselect > =C2=A0 =C2=A0 =C2=A0 status: active > =C2=A0 =C2=A0 =C2=A0 laggproto lacp > =C2=A0 =C2=A0 =C2=A0 laggport: em1 flags=3D1c > =C2=A0 =C2=A0 =C2=A0 laggport: em0 flags=3D1c > > show lacp neighbor =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Flags: =C2=A0S - Device= is > requesting Slow LACPDUs =C2=A0 =C2=A0 =C2=A0 F - Device is requesting Fas= t LACPDUs > =C2=A0 =C2=A0 =C2=A0 A - Device is in Active mode =C2=A0 =C2=A0 =C2=A0 P = - Device is in Passive mode > Channel group 2 neighbors > > Partner's information: > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 Partner Partner =C2=A0 LACP Partner =C2=A0Par= tner =C2=A0 Partner =C2=A0Partner > Partner > Port =C2=A0 =C2=A0 =C2=A0Flags =C2=A0 State =C2=A0 =C2=A0 Port Priority A= dmin Key Oper Key Port Number > Port State > Gi3/35 =C2=A0 =C2=A0SA =C2=A0 =C2=A0 =C2=A0bndl =C2=A0 =C2=A0 =C2=A032768= =C2=A0 =C2=A0 =C2=A0 =C2=A0 0x0 =C2=A0 =C2=A0 =C2=A0 0x90 =C2=A0 =C2=A0 0x= 1 > 0x3D =C2=A0Gi3/43 =C2=A0 =C2=A0SA =C2=A0 =C2=A0 =C2=A0bndl =C2=A0 =C2=A0 = =C2=A032768 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0x0 =C2=A0 =C2=A0 =C2=A0 0x90 =C2= =A0 =C2=A0 0x2 > =C2=A0 0x3D > > Stats: > > =C2=A0 =C2=A0 Interface =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Traffic =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Peak =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0Total > =C2=A0 =C2=A0 =C2=A0 =C2=A0 lagg0 =C2=A0in =C2=A0 =C2=A0 =C2=A00.351 KB/s= =C2=A0 =C2=A0 =C2=A0 =C2=A0117.349 MB/s =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A02.695 GB > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0out =C2=A0 =C2=A0 = 0.345 KB/s =C2=A0 =C2=A0 =C2=A0 =C2=A0114.183 MB/s =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A08.103 GB > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 em1 =C2=A0in =C2=A0 =C2=A0 =C2=A00.233= KB/s =C2=A0 =C2=A0 =C2=A0 =C2=A0117.349 MB/s =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A02.695 GB > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0out =C2=A0 =C2=A0 = 0.000 KB/s =C2=A0 =C2=A0 =C2=A0 =C2=A0132.535 MB/s =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A08.890 GB > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 em0 =C2=A0in =C2=A0 =C2=A0 =C2=A00.116= KB/s =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02.701 KB/s =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0331.405 KB > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0out =C2=A0 =C2=A0 = 0.345 KB/s =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A09.093 KB/s =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0631.883 KB > > > Name =C2=A0 =C2=A0Mtu Network =C2=A0 =C2=A0 =C2=A0 Address =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Ipkts Ierrs =C2=A0 =C2=A0Opkts Oerrs > =C2=A0Coll > em0 =C2=A0 =C2=A01500 =C2=A0 =C2=A0 =C2=A000:30:48:33:ec:44 =C2= =A0 =C2=A0 5381 =C2=A0 =C2=A0 0 =C2=A0 =C2=A0 5188 =C2=A0 =C2=A0 0 > =C2=A0 0 > em1 =C2=A0 =C2=A01500 =C2=A0 =C2=A0 =C2=A000:30:48:33:ec:44 =C2= =A05987608 =C2=A0 =C2=A0 0 =C2=A04015584 =C2=A0 =C2=A0 0 > =C2=A0 0 > lo0 =C2=A0 16384 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0 =C2=A0 =C2=A0= 0 =C2=A0 =C2=A0 =C2=A0 =C2=A00 =C2=A0 =C2=A0 0 > =C2=A0 0 > lo0 =C2=A0 16384 your-net =C2=A0 =C2=A0 =C2=A0localhost =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00 =C2=A0 =C2=A0 - =C2=A0 =C2=A0 =C2= =A0 =C2=A00 =C2=A0 =C2=A0 - > =C2=A0 - > lagg0 =C2=A01500 =C2=A0 =C2=A0 =C2=A000:30:48:33:ec:44 =C2=A0599= 2849 =C2=A0 =C2=A0 0 =C2=A04016823 =C2=A0 =C2=A0 8 > =C2=A0 0 > lagg0 =C2=A01500 10.10.1.0 =C2=A0 test =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= 5985503 =C2=A0 =C2=A0 - =C2=A06475013 =C2=A0 =C2=A0 - =C2=A0 =C2=A0 - > lagg0 =C2=A01500 10.10.1.83/ jail1 =C2=A0 =C2=A0 =C2=A0 19 =C2=A0 =C2=A0 = - =C2=A0 =C2=A0 =C2=A0 =C2=A00 =C2=A0 =C2=A0 - =C2=A0 =C2=A0 - > > > Anyone got any ideas, as far as I can see lacp is negotiating correctly j= ust > no balancing is happening :( > > =C2=A0 Regards > =C2=A0 Steve > What types of traffic streams are you testing this with? if_lagg will use the SRC/DST MACs and IP addresses for IP traffic to decide which member port of the lagg to sent the traffic out to, balancing of incoming traffic should be done by the Cisco on the same principle. Try a different laggproto for the if_lagg interface e.g. roundrobin with channel-group mode on set on the switchports. cheers, Shteryana From owner-freebsd-net@FreeBSD.ORG Wed Jan 27 14:07:27 2010 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 874EF1065672 for ; Wed, 27 Jan 2010 14:07:27 +0000 (UTC) (envelope-from nazeemnss@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3EFB78FC08 for ; Wed, 27 Jan 2010 14:07:26 +0000 (UTC) Received: by vws18 with SMTP id 18so264975vws.13 for ; Wed, 27 Jan 2010 06:07:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=D4H+Bg613KEQzK0/Xbgxktcy++iTE2j3zRWHRiSW5DA=; b=LKaH1aNBKSTMe22sDcZFTOWVFhYgwRCWHmf18dmMvQzlFjjFXycNoEoVpVFwv9ZiSw uZ3XrkANoNFri1eJoX/JcPhX/hGrrN3Y55Q1rcDZvIYmUI8OorYwwSn2TwcrxzywMc2P elqxoFN0rUezYB0ARvlXQYernwU6GsVrpoqeY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=AR0Ax84hLEV99Wlhe/LbSYz440Zo9eez+6iLvxlEhnMPcPrQTGF9dHhTj3vnXcl4r2 a37XRn8upL/Y8LvfmhHNdQSzsISz26Ypsz9qQYPzYeMzBYfk0oNcyOgj3vtjoaXghxm1 RI+1vSCNdjb7HaOZB449XTn1hpujviV82IihA= MIME-Version: 1.0 Received: by 10.220.89.66 with SMTP id d2mr2845143vcm.14.1264600877682; Wed, 27 Jan 2010 06:01:17 -0800 (PST) Date: Wed, 27 Jan 2010 19:31:17 +0530 Message-ID: <7609d8391001270601m489ab6e6xe956d1539f2cbe4e@mail.gmail.com> From: =?UTF-8?B?TmF6ZWVtINmG2KzZhSDZhNiv2YrZhg==?= To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: MROUTED: Problem with vif installation 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, 27 Jan 2010 14:07:27 -0000 Hi I get this error when running mrouted -d /etc/mrouted.conf is: tunnel 10.129.869.152 10.105.12.38 19:20:30.460 SENT neighbor probe from 10.129.86.152 to 224.0.0.4 19:20:30.461 SENT neighbor probe from 10.129.86.152 to 10.105.12.38 19:20:35.480 mrouted version 3.9-beta3+IOS12 19:20:35.480 Installing vifs in kernel... 19:20:35.480 vif #0, phyint 192.168.1.1 19:20:35.480 vif #1, phyint 10.129.86.152 19:20:35.481 vif #2, tunnel 10.129.86.152 -> 10.105.12.38 19:20:35.481 setsockopt MRT_ADD_VIF on vif 2: Operation not supported Can you please help me? -Nazeem From owner-freebsd-net@FreeBSD.ORG Wed Jan 27 14:15:40 2010 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 52A6D10656A6 for ; Wed, 27 Jan 2010 14:15:40 +0000 (UTC) (envelope-from nazeemnss@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0AEEB8FC21 for ; Wed, 27 Jan 2010 14:15:39 +0000 (UTC) Received: by vws18 with SMTP id 18so267944vws.13 for ; Wed, 27 Jan 2010 06:15:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=i133N1U5gqH/qJzztXKThF0l2B/nkoqtAd5hBNcmBIw=; b=ptvQUIUJg8Te4omM+n+tAotuaqCuvOI2Gw+Om5tXCYQhO7ce6CpabeObjTuZ2s+4ue NSo26o5r3MV4T8h/stcnIM+s2+6G+B/ZrwC6kSXsa3KzcH9qsSadRzPr3gtyZ/77WXXy 1X3DyKzQGmaky6bH0ZBlf44WkpYqik2vVdL+E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=smzZX1gAJnf5lxDnaKGAxKv7HkLrUNhpKKwbH2niy9iWH2pY+l/va3/nSUGnnZ85RL V0kqO2I1vSYX+AIE1uwo2gtGjwupoIveinfQAaXd/f1lhR/uQGfsPUJCzlaMYseSGSGJ JC6YEkKIsZXkHLoOpaTcPOkUCYX3f57978Hm8= MIME-Version: 1.0 Received: by 10.220.48.215 with SMTP id s23mr1426198vcf.46.1264600403190; Wed, 27 Jan 2010 05:53:23 -0800 (PST) Date: Wed, 27 Jan 2010 19:23:23 +0530 Message-ID: <7609d8391001270553g5097d704t1fbaf0ac6395597e@mail.gmail.com> From: =?UTF-8?B?TmF6ZWVtINmG2KzZhSDZhNiv2YrZhg==?= To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: MROUTED: Problem with vif installation 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, 27 Jan 2010 14:15:40 -0000 Hi I get this error when running mrouted -d /etc/mrouted.conf is: tunnel 10.129.869.152 10.105.12.38 19:20:30.460 SENT neighbor probe from 10.129.86.152 to 224.0.0.4 19:20:30.461 SENT neighbor probe from 10.129.86.152 to 10.105.12.38 19:20:35.480 mrouted version 3.9-beta3+IOS12 19:20:35.480 Installing vifs in kernel... 19:20:35.480 vif #0, phyint 192.168.1.1 19:20:35.480 vif #1, phyint 10.129.86.152 19:20:35.481 vif #2, tunnel 10.129.86.152 -> 10.105.12.38 19:20:35.481 setsockopt MRT_ADD_VIF on vif 2: Operation not supported Can you please help me? -Nazeem From owner-freebsd-net@FreeBSD.ORG Wed Jan 27 15:26:03 2010 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 0C2A6106566B for ; Wed, 27 Jan 2010 15:26:03 +0000 (UTC) (envelope-from prvs=1643314351=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 700518FC0A for ; Wed, 27 Jan 2010 15:26:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=multiplay.co.uk; s=Multiplay; t=1264605958; x=1265210758; q=dns/txt; h=Received: Message-ID:From:To:Cc:References:Subject:Date:MIME-Version: Content-Type:Content-Transfer-Encoding; bh=mvO7jSI0svuYjAw0qEDyo Jb7hwzkMe5u9Ij/LGuz/i4=; b=nX8M7DYbJCNO8NJth68I0E7pq6rhTk5J2yJQI 0Nyu1J1ETkK9aH9zi/rlJ8+hKKECd6M0afDBqwQ07NGKnnlyc7LQMLB98JSjlgRQ GBW8HW14Wz+18EyDdp1RWmV5d3Wxw9BbYzQyB+pDLFab88hIiV212r7hrCSLqdkT ILUx+M= X-MDAV-Processed: mail1.multiplay.co.uk, Wed, 27 Jan 2010 15:25:58 +0000 Received: from r2d2 by mail1.multiplay.co.uk (MDaemon PRO v10.0.4) with ESMTP id md50009320890.msg; Wed, 27 Jan 2010 15:25:56 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Wed, 27 Jan 2010 15:25:56 +0000 (not processed: message from trusted or authenticated source) X-Authenticated-Sender: Killing@multiplay.co.uk X-MDRemoteIP: 213.123.247.160 X-Return-Path: prvs=1643314351=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <251ACDBA39F244B7B8D1520DE3C95DF1@multiplay.co.uk> From: "Steven Hartland" To: References: <8E2B6E11A79B4958B94B44A41C7D4298@multiplay.co.uk> <61b573981001270543k6514a5g8d4f679777b69b49@mail.gmail.com> Date: Wed, 27 Jan 2010 15:25:56 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: freebsd-net@freebsd.org Subject: Re: Problems getting lagg to balance using lacp 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, 27 Jan 2010 15:26:03 -0000 ----- Original Message ----- From: "Shteryana Shopova" > What types of traffic streams are you testing this with? if_lagg will > use the SRC/DST MACs and IP addresses for IP traffic to decide which > member port of the lagg to sent the traffic out to, balancing of > incoming traffic should be done by the Cisco on the same principle. > Try a different laggproto for the if_lagg interface e.g. roundrobin > with channel-group mode on set on the switchports. I was testing with iperf to and from two other machines on the network. If I tested with one machine I got 1g throughput, with 2 machines I got ~500Mbps on each, for both inbound and outbound on em1. == laggproto lacp + channel-group 2 mode active == Got the same with both inbound and outbound connection == laggproto fec + channel-group 2 mode on == Got the same with both inbound and outbound connection == laggproto loadbalance + channel-group 2 mode on == Got the same with both inbound and outbound connection == laggproto roundrobin + channel-group 2 mode on ==, Instead of 1Gbps throughput on one interface I get 500Mbps on each for outbound only still no change with inbound. Any other ideas? Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-net@FreeBSD.ORG Wed Jan 27 15:52:18 2010 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 DF4611065670 for ; Wed, 27 Jan 2010 15:52:18 +0000 (UTC) (envelope-from shteryana@gmail.com) Received: from mail-ew0-f218.google.com (mail-ew0-f218.google.com [209.85.219.218]) by mx1.freebsd.org (Postfix) with ESMTP id 6F34C8FC1B for ; Wed, 27 Jan 2010 15:52:18 +0000 (UTC) Received: by ewy10 with SMTP id 10so1403562ewy.3 for ; Wed, 27 Jan 2010 07:52:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:reply-to:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=6Wb1bmqfNmQ68ATMmirJ5gtyGIjg4lJ3x6/70ObWh7w=; b=XR6zqq2z1GpqjQpNBp+U1P6eZZWf9Zil6lgCZZOyo4+6ik/ixSaZLTZGAMEhDqHw8P 6vx2m0TOpH3RBpR1a3m7gejdz5l8mu8t3jxe1Pf4zJOE/852TwMmR3gc36KkxbYaIWrw nQBHlycm4EmtiEG10fb27uiVPSZiJQ5o+yhzE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:reply-to:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=KKARZgL5Yb6Vjxsqq2fupHaW8Tt4ulNWnyeH4Us677DfRdR2ThrOSrRZc7jBsyFuTS i70nobHnvA3ucgsnq4WlfkGpmoOsQTXDYFe+9twAS9P78Y02TbQ6PYHe0+nSAmdkwQva OyRLU9PpUl9jqLjxV8/xzMetSvxcl8QkyjJ94= MIME-Version: 1.0 Sender: shteryana@gmail.com Received: by 10.213.100.197 with SMTP id z5mr4277961ebn.93.1264607537405; Wed, 27 Jan 2010 07:52:17 -0800 (PST) In-Reply-To: <251ACDBA39F244B7B8D1520DE3C95DF1@multiplay.co.uk> References: <8E2B6E11A79B4958B94B44A41C7D4298@multiplay.co.uk> <61b573981001270543k6514a5g8d4f679777b69b49@mail.gmail.com> <251ACDBA39F244B7B8D1520DE3C95DF1@multiplay.co.uk> Date: Wed, 27 Jan 2010 17:52:17 +0200 X-Google-Sender-Auth: 4ea32f84780dfea1 Message-ID: <61b573981001270752q4e21a8a9ldf19718ca3fb474c@mail.gmail.com> From: Shteryana Shopova To: Steven Hartland Content-Type: text/plain; charset=UTF-8 Cc: freebsd-net@freebsd.org Subject: Re: Problems getting lagg to balance using lacp X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: syrinx@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 15:52:19 -0000 On Wed, Jan 27, 2010 at 5:25 PM, Steven Hartland wrote: > > ----- Original Message ----- From: "Shteryana Shopova" > >> What types of traffic streams are you testing this with? if_lagg will >> use the SRC/DST MACs and IP addresses for IP traffic to decide which >> member port of the lagg to sent the traffic out to, balancing of >> incoming traffic should be done by the Cisco on the same principle. >> Try a different laggproto for the if_lagg interface e.g. roundrobin >> with channel-group mode on set on the switchports. > > I was testing with iperf to and from two other machines on the network. > > If I tested with one machine I got 1g throughput, with 2 machines I > got ~500Mbps on each, for both inbound and outbound on em1. > > == laggproto lacp + channel-group 2 mode active == > Got the same with both inbound and outbound connection > > == laggproto fec + channel-group 2 mode on == > Got the same with both inbound and outbound connection > > == laggproto loadbalance + channel-group 2 mode on == > Got the same with both inbound and outbound connection > > == laggproto roundrobin + channel-group 2 mode on ==, > Instead of 1Gbps throughput on one interface I get 500Mbps on each for > outbound only still no change with inbound. > > Any other ideas? > > Inbound load balancing is controlled by the Cisco - try playing with different options for - I guess src-dst-port option (if available) should give better results. cheers, Shteryana From owner-freebsd-net@FreeBSD.ORG Wed Jan 27 16:33:12 2010 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 79F52106568D; Wed, 27 Jan 2010 16:33:12 +0000 (UTC) (envelope-from prvs=1643314351=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id DB2E28FC1F; Wed, 27 Jan 2010 16:33:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=multiplay.co.uk; s=Multiplay; t=1264609987; x=1265214787; q=dns/txt; h=Received: Message-ID:From:To:Cc:References:Subject:Date:MIME-Version: Content-Type:Content-Transfer-Encoding; bh=9hgXRncJF2Q1SOM9cggXN FUW/m2VPLKRqXkwVBs5KDQ=; b=VJI+subhjHgJRxQKlevH85TkAKk8CNbGUX6lX ujRKu6W7mg5O+iWF4Cea62ijJ6y/lsFh90E3jjGWFccQlEGWfs8fLnZi9VvE1UFJ lWRSoaCTqTflvfnYZBHrKeRRzpmWe7zQRTXj1k/fB+0gq47Vtuy4phnZ2haaPZNZ LWfw+s= X-MDAV-Processed: mail1.multiplay.co.uk, Wed, 27 Jan 2010 16:33:07 +0000 Received: from r2d2 by mail1.multiplay.co.uk (MDaemon PRO v10.0.4) with ESMTP id md50009321742.msg; Wed, 27 Jan 2010 16:33:07 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Wed, 27 Jan 2010 16:33:07 +0000 (not processed: message from trusted or authenticated source) X-Authenticated-Sender: Killing@multiplay.co.uk X-MDRemoteIP: 213.123.247.160 X-Return-Path: prvs=1643314351=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <3B80DBAE9B734A4187B8A0DF8FFA1706@multiplay.co.uk> From: "Steven Hartland" To: References: <8E2B6E11A79B4958B94B44A41C7D4298@multiplay.co.uk><61b573981001270543k6514a5g8d4f679777b69b49@mail.gmail.com><251ACDBA39F244B7B8D1520DE3C95DF1@multiplay.co.uk> <61b573981001270752q4e21a8a9ldf19718ca3fb474c@mail.gmail.com> Date: Wed, 27 Jan 2010 16:33:03 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: freebsd-net@freebsd.org Subject: Re: Problems getting lagg to balance using lacp 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, 27 Jan 2010 16:33:12 -0000 ----- Original Message ----- From: "Shteryana Shopova" > Inbound load balancing is controlled by the Cisco - try playing with > different options for - I guess > src-dst-port option (if available) should give better results. Hmm, I believe the Cisco side is fine as there is an existing port channel between the switch we are testing this on an another 6509 and that's balancing perfectly. Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-net@FreeBSD.ORG Wed Jan 27 19:14:54 2010 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 792FB106566C for ; Wed, 27 Jan 2010 19:14:54 +0000 (UTC) (envelope-from egorenar@googlemail.com) Received: from mail-ew0-f218.google.com (mail-ew0-f218.google.com [209.85.219.218]) by mx1.freebsd.org (Postfix) with ESMTP id 0BD4C8FC0A for ; Wed, 27 Jan 2010 19:14:53 +0000 (UTC) Received: by ewy10 with SMTP id 10so1614659ewy.3 for ; Wed, 27 Jan 2010 11:14:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=aGk1+Z5hBQt/EvgdymWLUmUqZbczhXvLgMU7R+6tMNk=; b=JmpitbUnFeP46vm5jt6sreFhnSFj/KmlNVi8mtnEEWCB9sWCdbwArKIXN9QVRNxCpb Z2XRjM/mQWguzhUeMG2fXOlD/vFUbfepW1GqR3W8PyCoMNCmeGBPAgRZpJecQqqMQkgy tL+3yY8JCs7w1ydron+hjBENIvu7p9aQYyO6A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=Sl212mmaqsxkaY7WvCg8r5fQ6yWsrpOKO0IV5N72HK7GiPKE0C/Yg84S8Mia6zCthX qRZJE5HY9RGHewyKKuu09rfsu27XYnZhChVH01+Cb2m5KlQgwFdMNJ+fhU4JNRRx7GYP dA+4i5hXmqhuwRKRtRgBitR5iNhwmBkbEphs0= MIME-Version: 1.0 Received: by 10.213.37.147 with SMTP id x19mr361115ebd.58.1264619286033; Wed, 27 Jan 2010 11:08:06 -0800 (PST) In-Reply-To: <2d3b7e441001271104j14836df4j14428d34561dead1@mail.gmail.com> References: <2d3b7e441001271104j14836df4j14428d34561dead1@mail.gmail.com> Date: Wed, 27 Jan 2010 20:08:06 +0100 Message-ID: <2d3b7e441001271108p2a40dbbbwaa6af9679d61ab@mail.gmail.com> From: Alexander Egorenkov To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: A-MPDU transmission in net80211 on FreeBSD 8 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, 27 Jan 2010 19:14:54 -0000 Sorry, i posted the wrong comment. Here is the comment which i don't understand: /* * NB: don't assign a sequence # to potential * aggregates; we expect this happens at the * point the frame comes off any aggregation q * as otherwise we may introduce holes in the * BA sequence space and/or make window accouting * more difficult. * * XXX may want to control this with a driver * capability; this may also change when we pull * aggregation up into net80211 */ Thanks. On Wed, Jan 27, 2010 at 8:04 PM, Alexander Egorenkov < egorenar@googlemail.com> wrote: > > Hi, > > i'm implementing a device driver for a 802.11n NIC under FreeBSD 8 > und experimented with A-MPDU transmission. I looked into net80211 code > and there is some code which implements this feature but it worked not very > well for me. > I noticed e.g. that sequence numbers are not assigned to A-MPDU frames > and found this comment in file ieee80211_output.c : > > > /* > * Check if A-MPDU tx aggregation is setup or if we > * should try to enable it. The sta must be associated > * with HT and A-MPDU enabled for use. When the policy > * routine decides we should enable A-MPDU we issue an > * ADDBA request and wait for a reply. The frame being > * encapsulated will go out w/o using A-MPDU, or possibly > * it might be collected by the driver and held/retransmit. > * The default ic_ampdu_enable routine handles staggering > * ADDBA requests in case the receiver NAK's us or we are > * otherwise unable to establish a BA stream. > */ > > Can somebody elaborate this description to me please. > > Thanks. > > ALex. > > From owner-freebsd-net@FreeBSD.ORG Wed Jan 27 19:31:46 2010 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 13CEB1065693 for ; Wed, 27 Jan 2010 19:31:46 +0000 (UTC) (envelope-from egorenar@googlemail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by mx1.freebsd.org (Postfix) with ESMTP id A19708FC16 for ; Wed, 27 Jan 2010 19:31:45 +0000 (UTC) Received: by ey-out-2122.google.com with SMTP id 9so1533554eyd.9 for ; Wed, 27 Jan 2010 11:31:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=GrpyYnE/solfA8eHNkOPzuxMQk07PCfE5Aqd66gOQL8=; b=oj0wTnN9oOBPM0JtWJExUVH902rryVUngtVXur+Md0IWbuWdeyTh1XfX1kAqjSm2n/ jjDejLxM5v9BtmMsKxO0Wc3Mq4b0EN4KsOcaJ8aMp0Bou7V9z0JMsQlrptWAko9y28+7 Baswcr3dmfxS4jtloGLTOwLoQy3Rm2SGoGLoY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=ptcO8q3IVxMivnmRDat2NL5zA0xJeIW8JJ865sjF9Ab/6PxFMjsHBU5QsF/eamIlU8 GlQshsbEfdeC8YxXQZ+ntZYOpT5Fuyilti0LwDG3U461NttLuMETDQVh2BU+jOmQdAh6 4PdXxw1C+S1yXBYPkAerYZqJzkDjjrjLIhHnw= MIME-Version: 1.0 Received: by 10.213.0.148 with SMTP id 20mr1493410ebb.51.1264619049354; Wed, 27 Jan 2010 11:04:09 -0800 (PST) Date: Wed, 27 Jan 2010 20:04:09 +0100 Message-ID: <2d3b7e441001271104j14836df4j14428d34561dead1@mail.gmail.com> From: Alexander Egorenkov To: freebsd-net@freebsd.org X-Mailman-Approved-At: Wed, 27 Jan 2010 19:47:09 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: A-MPDU transmission in net80211 on FreeBSD 8 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, 27 Jan 2010 19:31:46 -0000 Hi, i'm implementing a device driver for a 802.11n NIC under FreeBSD 8 und experimented with A-MPDU transmission. I looked into net80211 code and there is some code which implements this feature but it worked not very well for me. I noticed e.g. that sequence numbers are not assigned to A-MPDU frames and found this comment in file ieee80211_output.c : /* * Check if A-MPDU tx aggregation is setup or if we * should try to enable it. The sta must be associated * with HT and A-MPDU enabled for use. When the policy * routine decides we should enable A-MPDU we issue an * ADDBA request and wait for a reply. The frame being * encapsulated will go out w/o using A-MPDU, or possibly * it might be collected by the driver and held/retransmit. * The default ic_ampdu_enable routine handles staggering * ADDBA requests in case the receiver NAK's us or we are * otherwise unable to establish a BA stream. */ Can somebody elaborate this description to me please. Thanks. ALex. From owner-freebsd-net@FreeBSD.ORG Thu Jan 28 01:15:08 2010 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 CC329106568F for ; Thu, 28 Jan 2010 01:15:08 +0000 (UTC) (envelope-from sam@ip6.com.au) Received: from mail01.ip6.com.au (ns1.ip6.com.au [125.255.112.202]) by mx1.freebsd.org (Postfix) with ESMTP id 8A7758FC17 for ; Thu, 28 Jan 2010 01:15:08 +0000 (UTC) Received: from mail01.ip6.com.au (localhost [127.0.0.1]) by mail01.ip6.com.au (Postfix) with ESMTP id 822692882E; Thu, 28 Jan 2010 11:58:51 +1100 (EST) Received: by mail01.ip6.com.au (Postfix, from userid 500) id 5B2602882D; Thu, 28 Jan 2010 11:58:51 +1100 (EST) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail01.ip6.com.au X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, FH_DATE_PAST_20XX autolearn=no version=3.2.5 Received: from [10.250.250.37] (unknown [203.41.110.193]) by mail01.ip6.com.au (Postfix) with ESMTPA id 41F5328538; Thu, 28 Jan 2010 11:58:50 +1100 (EST) Message-ID: <4B60E157.9090200@ip6.com.au> Date: Thu, 28 Jan 2010 11:59:03 +1100 From: sam User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Sherin George References: <7f14551c1001231916s1c142b21j916ae406ea71bd97@mail.gmail.com> In-Reply-To: <7f14551c1001231916s1c142b21j916ae406ea71bd97@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-net@freebsd.org Subject: Re: Strange network issue in freebsd 8 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, 28 Jan 2010 01:15:09 -0000 Hi, Is this problem still happening? Cheers Sam On 24/01/2010 2:16 PM, Sherin George wrote: > Hello, > > I am facing some sort of strange network issue in a freebsd server > occasionally. > > OS: FreeBSD 8.0-RELEASE - amd64 > > Now, I have updated to FreeBSD 8.0-RELEASE-p2 > > The servers loses network connection once in a few days. I logged into > console and verified that network is up. I even restarted network service > using following command. > > /etc/rc.d/netif restart > > Still, it didn't fix. > > I checked /var/log/messages, but I am not getting any clue. > > ============== > Jan 19 12:10:20 myserver kernel: GEOM_MIRROR: Device gm0: rebuilding > provider ad0 finished. > Jan 19 20:20:23 myserver nfsd[732]: select failed: Interrupted system call > Jan 19 20:21:07 myserver nfsd[732]: select failed: Interrupted system call > Jan 23 02:14:33 myserver login: ROOT LOGIN (root) ON ttyv0 > Jan 23 02:19:51 myserver kernel: ifa_del_loopback_route: deletion failed > Jan 23 02:19:57 myserver kernel: em0: link state changed to DOWN > Jan 23 02:20:02 myserver kernel: em0: link state changed to UP > Jan 23 02:29:58 myserver reboot: rebooted by root > Jan 23 02:29:58 myserver syslogd: exiting on signal 15 > Jan 23 02:31:31 myserver syslogd: kernel boot file is /boot/kernel/kernel > Jan 23 02:31:31 myserver kernel: Copyright (c) 1992-2009 The FreeBSD > Project. > Jan 23 02:31:31 myserver kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, > 1989, 1991, 1992, 1993, 1994 > Jan 23 02:31:31 myserver kernel: The Regents of the University of > California. All rights reserved. > Jan 23 02:31:31 myserver kernel: FreeBSD is a registered trademark of The > FreeBSD Foundation. > Jan 23 02:31:31 myserver kernel: FreeBSD 8.0-RELEASE #0: Sat Nov 21 15:02:08 > UTC 2009 > Jan 23 02:31:31 myserver kernel: root@mason.cse.buffalo.edu: > /usr/obj/usr/src/sys/GENERIC > Jan 23 02:31:31 myserver kernel: Timecounter "i8254" frequency 1193182 Hz > quality 0 > ============== > > Network, TCP stack all were up. It was pinging gateway even. But, traceroute > was not going beyond gateway. > > I believe the issue is not related to anything outside server since a reboot > always fixes the issue. > > I will be grateful for any advice that can help me in troubleshooting this > problem. > > -- > Best Regards, > Sherin > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > From owner-freebsd-net@FreeBSD.ORG Thu Jan 28 01:49:29 2010 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 2FD0F1065672 for ; Thu, 28 Jan 2010 01:49:29 +0000 (UTC) (envelope-from brett@lariat.net) Received: from lariat.net (lariat.net [66.119.58.2]) by mx1.freebsd.org (Postfix) with ESMTP id A5B068FC08 for ; Thu, 28 Jan 2010 01:49:28 +0000 (UTC) Received: (from root@localhost) by lariat.net (8.9.3/8.9.3) id SAA18331 for freebsd-net@freebsd.org; Wed, 27 Jan 2010 18:26:22 -0700 (MST) Date: Wed, 27 Jan 2010 18:26:22 -0700 (MST) From: Brett Glass Message-Id: <201001280126.SAA18331@lariat.net> To: freebsd-net@freebsd.org Subject: Ralink 28xx series drivers? 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, 28 Jan 2010 01:49:29 -0000 I am trying to make FreeBSD 8.0 fully functional on an ASUS mini-workstation that seems to have a Ralink RT2860 card inside. The "ral" driver for FreeBSD doesn't recognize the card. Apparently, OpenBSD does have a driver for this chip. Is anyone porting it? Please copy me on responses, as I am not a full time subscriber of this list. --Brett Glass From owner-freebsd-net@FreeBSD.ORG Thu Jan 28 02:05:52 2010 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 2B07D1065670; Thu, 28 Jan 2010 02:05:52 +0000 (UTC) (envelope-from list@sheringeorge.co.cc) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by mx1.freebsd.org (Postfix) with ESMTP id F006E8FC16; Thu, 28 Jan 2010 02:05:51 +0000 (UTC) Received: by pwi15 with SMTP id 15so156269pwi.3 for ; Wed, 27 Jan 2010 18:05:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.107.6 with SMTP id j6mr7099399rvm.288.1264644351037; Wed, 27 Jan 2010 18:05:51 -0800 (PST) In-Reply-To: <4B60E157.9090200@ip6.com.au> References: <7f14551c1001231916s1c142b21j916ae406ea71bd97@mail.gmail.com> <4B60E157.9090200@ip6.com.au> Date: Thu, 28 Jan 2010 07:35:51 +0530 Message-ID: <7f14551c1001271805w758c3e95s569365ad468ab9ae@mail.gmail.com> From: Sherin George To: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org, freebsd-questions@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: Strange network issue in freebsd 8 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, 28 Jan 2010 02:05:52 -0000 Hello Sam, The problem happened today again. I am getting this message on traceroute =============== traceroute: findsaddr: write: No such process ================ When running a ping to 8.8.8.8, it says following. =================== ping: sendto: No route to host ==================== Please see the result of "netstat -rn" command. ============ myserver# netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default XXX.XXX.XXX.241 UGS 62 209247 em0 127.0.0.1 link#3 UH 0 0 lo0 XXX.XXX.XXX.240/29 link#1 U 0 0 em0 XXX.XXX.XXX.242 link#1 UHS 0 0 lo0 Internet6: Destination Gateway Flags Netif Expire ::1 ::1 UH lo0 fe80::%lo0/64 link#3 U lo0 fe80::1%lo0 link#3 UHS lo0 ff01:3::/32 fe80::1%lo0 U lo0 ff02::%lo0/32 fe80::1%lo0 U lo0 ============= Note: I have replaced first three octets. I have checked netstat -m also. It is also not showing any problem. Could anyone please help me to sort out this issue. -- Thanks, Sherin On Thu, Jan 28, 2010 at 6:29 AM, sam wrote: > Hi, > > Is this problem still happening? > > Cheers > Sam > > > On 24/01/2010 2:16 PM, Sherin George wrote: > >> Hello, >> >> I am facing some sort of strange network issue in a freebsd server >> occasionally. >> >> OS: FreeBSD 8.0-RELEASE - amd64 >> >> Now, I have updated to FreeBSD 8.0-RELEASE-p2 >> >> The servers loses network connection once in a few days. I logged into >> console and verified that network is up. I even restarted network service >> using following command. >> >> /etc/rc.d/netif restart >> >> Still, it didn't fix. >> >> I checked /var/log/messages, but I am not getting any clue. >> >> ============== >> Jan 19 12:10:20 myserver kernel: GEOM_MIRROR: Device gm0: rebuilding >> provider ad0 finished. >> Jan 19 20:20:23 myserver nfsd[732]: select failed: Interrupted system call >> Jan 19 20:21:07 myserver nfsd[732]: select failed: Interrupted system call >> Jan 23 02:14:33 myserver login: ROOT LOGIN (root) ON ttyv0 >> Jan 23 02:19:51 myserver kernel: ifa_del_loopback_route: deletion failed >> Jan 23 02:19:57 myserver kernel: em0: link state changed to DOWN >> Jan 23 02:20:02 myserver kernel: em0: link state changed to UP >> Jan 23 02:29:58 myserver reboot: rebooted by root >> Jan 23 02:29:58 myserver syslogd: exiting on signal 15 >> Jan 23 02:31:31 myserver syslogd: kernel boot file is /boot/kernel/kernel >> Jan 23 02:31:31 myserver kernel: Copyright (c) 1992-2009 The FreeBSD >> Project. >> Jan 23 02:31:31 myserver kernel: Copyright (c) 1979, 1980, 1983, 1986, >> 1988, >> 1989, 1991, 1992, 1993, 1994 >> Jan 23 02:31:31 myserver kernel: The Regents of the University of >> California. All rights reserved. >> Jan 23 02:31:31 myserver kernel: FreeBSD is a registered trademark of The >> FreeBSD Foundation. >> Jan 23 02:31:31 myserver kernel: FreeBSD 8.0-RELEASE #0: Sat Nov 21 >> 15:02:08 >> UTC 2009 >> Jan 23 02:31:31 myserver kernel: root@mason.cse.buffalo.edu: >> /usr/obj/usr/src/sys/GENERIC >> Jan 23 02:31:31 myserver kernel: Timecounter "i8254" frequency 1193182 Hz >> quality 0 >> ============== >> >> Network, TCP stack all were up. It was pinging gateway even. But, >> traceroute >> was not going beyond gateway. >> >> I believe the issue is not related to anything outside server since a >> reboot >> always fixes the issue. >> >> I will be grateful for any advice that can help me in troubleshooting this >> problem. >> >> -- >> Best Regards, >> Sherin >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> >> >> > > From owner-freebsd-net@FreeBSD.ORG Thu Jan 28 02:55:33 2010 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 2DCDB1065672 for ; Thu, 28 Jan 2010 02:55:33 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id 1615A8FC08 for ; Thu, 28 Jan 2010 02:55:32 +0000 (UTC) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id o0S2tWBW015092; Wed, 27 Jan 2010 18:55:32 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 27 Jan 2010 18:52:41 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Strange network issue in freebsd 8 Thread-Index: AcqfvpM4rcqcQAOsSbKHSGYJksHSPgABmJy+ References: <7f14551c1001231916s1c142b21j916ae406ea71bd97@mail.gmail.com><4B60E157.9090200@ip6.com.au> <7f14551c1001271805w758c3e95s569365ad468ab9ae@mail.gmail.com> From: "Li, Qing" To: "Sherin George" , , , Cc: Subject: RE: Strange network issue in freebsd 8 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, 28 Jan 2010 02:55:33 -0000 I have been consumed by day job 200% of my time. I have some free time tonight and can work with you off-line. Is it possible for you to update to the latest stable-8 kernel=20 and we start from there ? -- Qing -----Original Message----- From: owner-freebsd-net@freebsd.org on behalf of Sherin George Sent: Wed 1/27/2010 6:05 PM To: freebsd-net@freebsd.org; freebsd-hackers@freebsd.org; = freebsd-questions@freebsd.org Subject: Re: Strange network issue in freebsd 8 =20 Hello Sam, The problem happened today again. I am getting this message on traceroute =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D traceroute: findsaddr: write: No such process =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D When running a ping to 8.8.8.8, it says following. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ping: sendto: No route to host =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Please see the result of "netstat -rn" command. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D myserver# netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif = Expire default XXX.XXX.XXX.241 UGS 62 209247 em0 127.0.0.1 link#3 UH 0 0 lo0 XXX.XXX.XXX.240/29 link#1 U 0 0 em0 XXX.XXX.XXX.242 link#1 UHS 0 0 lo0 Internet6: Destination Gateway Flags Netif Expire ::1 ::1 UH lo0 fe80::%lo0/64 link#3 U lo0 fe80::1%lo0 link#3 UHS lo0 ff01:3::/32 fe80::1%lo0 U lo0 ff02::%lo0/32 fe80::1%lo0 U lo0 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Note: I have replaced first three octets. I have checked netstat -m also. It is also not showing any problem. Could anyone please help me to sort out this issue. -- Thanks, Sherin On Thu, Jan 28, 2010 at 6:29 AM, sam wrote: > Hi, > > Is this problem still happening? > > Cheers > Sam > > > On 24/01/2010 2:16 PM, Sherin George wrote: > >> Hello, >> >> I am facing some sort of strange network issue in a freebsd server >> occasionally. >> >> OS: FreeBSD 8.0-RELEASE - amd64 >> >> Now, I have updated to FreeBSD 8.0-RELEASE-p2 >> >> The servers loses network connection once in a few days. I logged = into >> console and verified that network is up. I even restarted network = service >> using following command. >> >> /etc/rc.d/netif restart >> >> Still, it didn't fix. >> >> I checked /var/log/messages, but I am not getting any clue. >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> Jan 19 12:10:20 myserver kernel: GEOM_MIRROR: Device gm0: rebuilding >> provider ad0 finished. >> Jan 19 20:20:23 myserver nfsd[732]: select failed: Interrupted system = call >> Jan 19 20:21:07 myserver nfsd[732]: select failed: Interrupted system = call >> Jan 23 02:14:33 myserver login: ROOT LOGIN (root) ON ttyv0 >> Jan 23 02:19:51 myserver kernel: ifa_del_loopback_route: deletion = failed >> Jan 23 02:19:57 myserver kernel: em0: link state changed to DOWN >> Jan 23 02:20:02 myserver kernel: em0: link state changed to UP >> Jan 23 02:29:58 myserver reboot: rebooted by root >> Jan 23 02:29:58 myserver syslogd: exiting on signal 15 >> Jan 23 02:31:31 myserver syslogd: kernel boot file is = /boot/kernel/kernel >> Jan 23 02:31:31 myserver kernel: Copyright (c) 1992-2009 The FreeBSD >> Project. >> Jan 23 02:31:31 myserver kernel: Copyright (c) 1979, 1980, 1983, = 1986, >> 1988, >> 1989, 1991, 1992, 1993, 1994 >> Jan 23 02:31:31 myserver kernel: The Regents of the University of >> California. All rights reserved. >> Jan 23 02:31:31 myserver kernel: FreeBSD is a registered trademark of = The >> FreeBSD Foundation. >> Jan 23 02:31:31 myserver kernel: FreeBSD 8.0-RELEASE #0: Sat Nov 21 >> 15:02:08 >> UTC 2009 >> Jan 23 02:31:31 myserver kernel: root@mason.cse.buffalo.edu: >> /usr/obj/usr/src/sys/GENERIC >> Jan 23 02:31:31 myserver kernel: Timecounter "i8254" frequency = 1193182 Hz >> quality 0 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> Network, TCP stack all were up. It was pinging gateway even. But, >> traceroute >> was not going beyond gateway. >> >> I believe the issue is not related to anything outside server since a >> reboot >> always fixes the issue. >> >> I will be grateful for any advice that can help me in troubleshooting = this >> problem. >> >> -- >> Best Regards, >> Sherin >> _______________________________________________ >> 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 Thu Jan 28 03:03:40 2010 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 E9EEA106566C for ; Thu, 28 Jan 2010 03:03:40 +0000 (UTC) (envelope-from sam@ip6.com.au) Received: from mail01.ip6.com.au (ns1.ip6.com.au [125.255.112.202]) by mx1.freebsd.org (Postfix) with ESMTP id 6DB8F8FC13 for ; Thu, 28 Jan 2010 03:03:40 +0000 (UTC) Received: from mail01.ip6.com.au (localhost [127.0.0.1]) by mail01.ip6.com.au (Postfix) with ESMTP id 06F132882E; Thu, 28 Jan 2010 14:03:38 +1100 (EST) Received: by mail01.ip6.com.au (Postfix, from userid 500) id D48472882D; Thu, 28 Jan 2010 14:03:37 +1100 (EST) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail01.ip6.com.au X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, FH_DATE_PAST_20XX autolearn=no version=3.2.5 Received: from [10.250.250.37] (unknown [203.41.110.193]) by mail01.ip6.com.au (Postfix) with ESMTPA id 2CDF928538; Thu, 28 Jan 2010 14:03:37 +1100 (EST) Message-ID: <4B60FE95.7040209@ip6.com.au> Date: Thu, 28 Jan 2010 14:03:49 +1100 From: sam User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Sherin George References: <7f14551c1001231916s1c142b21j916ae406ea71bd97@mail.gmail.com> <4B60E157.9090200@ip6.com.au> <7f14551c1001271805w758c3e95s569365ad468ab9ae@mail.gmail.com> In-Reply-To: <7f14551c1001271805w758c3e95s569365ad468ab9ae@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-net@freebsd.org, freebsd-questions@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Strange network issue in freebsd 8 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, 28 Jan 2010 03:03:41 -0000 that s why I 've been so in doubt using freebsd AMD64 release. On 28/01/2010 1:05 PM, Sherin George wrote: > Hello Sam, > > The problem happened today again. > > I am getting this message on traceroute > > =============== > traceroute: findsaddr: write: No such process > ================ > > When running a ping to 8.8.8.8, it says following. > > =================== > ping: sendto: No route to host > ==================== > > Please see the result of "netstat -rn" command. > > ============ > myserver# netstat -rn > Routing tables > > Internet: > Destination Gateway Flags Refs Use Netif Expire > default XXX.XXX.XXX.241 UGS 62 209247 em0 > 127.0.0.1 link#3 UH 0 0 lo0 > XXX.XXX.XXX.240/29 link#1 U 0 0 em0 > XXX.XXX.XXX.242 link#1 UHS 0 0 lo0 > > Internet6: > Destination Gateway Flags > Netif Expire > ::1 ::1 UH > lo0 > fe80::%lo0/64 link#3 U > lo0 > fe80::1%lo0 link#3 UHS > lo0 > ff01:3::/32 fe80::1%lo0 U > lo0 > ff02::%lo0/32 fe80::1%lo0 U > lo0 > ============= > > Note: I have replaced first three octets. > > I have checked netstat -m also. It is also not showing any problem. > > Could anyone please help me to sort out this issue. > > -- > Thanks, > Sherin > > On Thu, Jan 28, 2010 at 6:29 AM, sam wrote: > > >> Hi, >> >> Is this problem still happening? >> >> Cheers >> Sam >> >> >> On 24/01/2010 2:16 PM, Sherin George wrote: >> >> >>> Hello, >>> >>> I am facing some sort of strange network issue in a freebsd server >>> occasionally. >>> >>> OS: FreeBSD 8.0-RELEASE - amd64 >>> >>> Now, I have updated to FreeBSD 8.0-RELEASE-p2 >>> >>> The servers loses network connection once in a few days. I logged into >>> console and verified that network is up. I even restarted network service >>> using following command. >>> >>> /etc/rc.d/netif restart >>> >>> Still, it didn't fix. >>> >>> I checked /var/log/messages, but I am not getting any clue. >>> >>> ============== >>> Jan 19 12:10:20 myserver kernel: GEOM_MIRROR: Device gm0: rebuilding >>> provider ad0 finished. >>> Jan 19 20:20:23 myserver nfsd[732]: select failed: Interrupted system call >>> Jan 19 20:21:07 myserver nfsd[732]: select failed: Interrupted system call >>> Jan 23 02:14:33 myserver login: ROOT LOGIN (root) ON ttyv0 >>> Jan 23 02:19:51 myserver kernel: ifa_del_loopback_route: deletion failed >>> Jan 23 02:19:57 myserver kernel: em0: link state changed to DOWN >>> Jan 23 02:20:02 myserver kernel: em0: link state changed to UP >>> Jan 23 02:29:58 myserver reboot: rebooted by root >>> Jan 23 02:29:58 myserver syslogd: exiting on signal 15 >>> Jan 23 02:31:31 myserver syslogd: kernel boot file is /boot/kernel/kernel >>> Jan 23 02:31:31 myserver kernel: Copyright (c) 1992-2009 The FreeBSD >>> Project. >>> Jan 23 02:31:31 myserver kernel: Copyright (c) 1979, 1980, 1983, 1986, >>> 1988, >>> 1989, 1991, 1992, 1993, 1994 >>> Jan 23 02:31:31 myserver kernel: The Regents of the University of >>> California. All rights reserved. >>> Jan 23 02:31:31 myserver kernel: FreeBSD is a registered trademark of The >>> FreeBSD Foundation. >>> Jan 23 02:31:31 myserver kernel: FreeBSD 8.0-RELEASE #0: Sat Nov 21 >>> 15:02:08 >>> UTC 2009 >>> Jan 23 02:31:31 myserver kernel: root@mason.cse.buffalo.edu: >>> /usr/obj/usr/src/sys/GENERIC >>> Jan 23 02:31:31 myserver kernel: Timecounter "i8254" frequency 1193182 Hz >>> quality 0 >>> ============== >>> >>> Network, TCP stack all were up. It was pinging gateway even. But, >>> traceroute >>> was not going beyond gateway. >>> >>> I believe the issue is not related to anything outside server since a >>> reboot >>> always fixes the issue. >>> >>> I will be grateful for any advice that can help me in troubleshooting this >>> problem. >>> >>> -- >>> Best Regards, >>> Sherin >>> _______________________________________________ >>> 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 Thu Jan 28 03:28:47 2010 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 114F9106566B; Thu, 28 Jan 2010 03:28:47 +0000 (UTC) (envelope-from list@sheringeorge.co.cc) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by mx1.freebsd.org (Postfix) with ESMTP id D57138FC0C; Thu, 28 Jan 2010 03:28:46 +0000 (UTC) Received: by pwi15 with SMTP id 15so199584pwi.3 for ; Wed, 27 Jan 2010 19:28:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.55.5 with SMTP id d5mr6619876rva.177.1264649325606; Wed, 27 Jan 2010 19:28:45 -0800 (PST) In-Reply-To: References: <7f14551c1001231916s1c142b21j916ae406ea71bd97@mail.gmail.com> <4B60E157.9090200@ip6.com.au> <7f14551c1001271805w758c3e95s569365ad468ab9ae@mail.gmail.com> Date: Thu, 28 Jan 2010 08:58:45 +0530 Message-ID: <7f14551c1001271928k112321e4s1338979bfb1e7d44@mail.gmail.com> From: Sherin George To: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org, freebsd-questions@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: Strange network issue in freebsd 8 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, 28 Jan 2010 03:28:47 -0000 Hello, Thanks Qing. I have already upgraded to latest patch as per per the advise of "freebsd-hackers" ============================== myserver# uname -a FreeBSD myserver.server.net 8.0-RELEASE-p2 FreeBSD 8.0-RELEASE-p2 #0: Tue Jan 5 21:11:58 UTC 2010 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 myserver# freebsd-update fetch Looking up update.FreeBSD.org mirrors... 3 mirrors found. Fetching metadata signature for 8.0-RELEASE from update4.FreeBSD.org... done. Fetching metadata index... done. Inspecting system... done. Preparing to download files... done. No updates needed to update system to 8.0-RELEASE-p2. ============================== -- Regards, Sherin On Thu, Jan 28, 2010 at 8:22 AM, Li, Qing wrote: > > I have been consumed by day job 200% of my time. > > I have some free time tonight and can work with you off-line. > Is it possible for you to update to the latest stable-8 kernel > and we start from there ? > > -- Qing > > > -----Original Message----- > From: owner-freebsd-net@freebsd.org on behalf of Sherin George > Sent: Wed 1/27/2010 6:05 PM > To: freebsd-net@freebsd.org; freebsd-hackers@freebsd.org; > freebsd-questions@freebsd.org > Subject: Re: Strange network issue in freebsd 8 > > Hello Sam, > > The problem happened today again. > > I am getting this message on traceroute > > =============== > traceroute: findsaddr: write: No such process > ================ > > When running a ping to 8.8.8.8, it says following. > > =================== > ping: sendto: No route to host > ==================== > > Please see the result of "netstat -rn" command. > > ============ > myserver# netstat -rn > Routing tables > > Internet: > Destination Gateway Flags Refs Use Netif Expire > default XXX.XXX.XXX.241 UGS 62 209247 em0 > 127.0.0.1 link#3 UH 0 0 lo0 > XXX.XXX.XXX.240/29 link#1 U 0 0 em0 > XXX.XXX.XXX.242 link#1 UHS 0 0 lo0 > > Internet6: > Destination Gateway Flags > Netif Expire > ::1 ::1 UH > lo0 > fe80::%lo0/64 link#3 U > lo0 > fe80::1%lo0 link#3 UHS > lo0 > ff01:3::/32 fe80::1%lo0 U > lo0 > ff02::%lo0/32 fe80::1%lo0 U > lo0 > ============= > > Note: I have replaced first three octets. > > I have checked netstat -m also. It is also not showing any problem. > > Could anyone please help me to sort out this issue. > > -- > Thanks, > Sherin > > On Thu, Jan 28, 2010 at 6:29 AM, sam wrote: > > > Hi, > > > > Is this problem still happening? > > > > Cheers > > Sam > > > > > > On 24/01/2010 2:16 PM, Sherin George wrote: > > > >> Hello, > >> > >> I am facing some sort of strange network issue in a freebsd server > >> occasionally. > >> > >> OS: FreeBSD 8.0-RELEASE - amd64 > >> > >> Now, I have updated to FreeBSD 8.0-RELEASE-p2 > >> > >> The servers loses network connection once in a few days. I logged into > >> console and verified that network is up. I even restarted network > service > >> using following command. > >> > >> /etc/rc.d/netif restart > >> > >> Still, it didn't fix. > >> > >> I checked /var/log/messages, but I am not getting any clue. > >> > >> ============== > >> Jan 19 12:10:20 myserver kernel: GEOM_MIRROR: Device gm0: rebuilding > >> provider ad0 finished. > >> Jan 19 20:20:23 myserver nfsd[732]: select failed: Interrupted system > call > >> Jan 19 20:21:07 myserver nfsd[732]: select failed: Interrupted system > call > >> Jan 23 02:14:33 myserver login: ROOT LOGIN (root) ON ttyv0 > >> Jan 23 02:19:51 myserver kernel: ifa_del_loopback_route: deletion failed > >> Jan 23 02:19:57 myserver kernel: em0: link state changed to DOWN > >> Jan 23 02:20:02 myserver kernel: em0: link state changed to UP > >> Jan 23 02:29:58 myserver reboot: rebooted by root > >> Jan 23 02:29:58 myserver syslogd: exiting on signal 15 > >> Jan 23 02:31:31 myserver syslogd: kernel boot file is > /boot/kernel/kernel > >> Jan 23 02:31:31 myserver kernel: Copyright (c) 1992-2009 The FreeBSD > >> Project. > >> Jan 23 02:31:31 myserver kernel: Copyright (c) 1979, 1980, 1983, 1986, > >> 1988, > >> 1989, 1991, 1992, 1993, 1994 > >> Jan 23 02:31:31 myserver kernel: The Regents of the University of > >> California. All rights reserved. > >> Jan 23 02:31:31 myserver kernel: FreeBSD is a registered trademark of > The > >> FreeBSD Foundation. > >> Jan 23 02:31:31 myserver kernel: FreeBSD 8.0-RELEASE #0: Sat Nov 21 > >> 15:02:08 > >> UTC 2009 > >> Jan 23 02:31:31 myserver kernel: root@mason.cse.buffalo.edu: > >> /usr/obj/usr/src/sys/GENERIC > >> Jan 23 02:31:31 myserver kernel: Timecounter "i8254" frequency 1193182 > Hz > >> quality 0 > >> ============== > >> > >> Network, TCP stack all were up. It was pinging gateway even. But, > >> traceroute > >> was not going beyond gateway. > >> > >> I believe the issue is not related to anything outside server since a > >> reboot > >> always fixes the issue. > >> > >> I will be grateful for any advice that can help me in troubleshooting > this > >> problem. > >> > >> -- > >> Best Regards, > >> Sherin > >> _______________________________________________ > >> 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 Thu Jan 28 03:30:30 2010 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 6B88E1065698 for ; Thu, 28 Jan 2010 03:30:30 +0000 (UTC) (envelope-from realliukai@gmail.com) Received: from mail-iw0-f199.google.com (mail-iw0-f199.google.com [209.85.223.199]) by mx1.freebsd.org (Postfix) with ESMTP id 1EE478FC22 for ; Thu, 28 Jan 2010 03:30:29 +0000 (UTC) Received: by iwn37 with SMTP id 37so308678iwn.30 for ; Wed, 27 Jan 2010 19:30:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=QHJnvFFHwb8O4b3McucyeTHnbaNBGVfUX6yIzDmNMs8=; b=YtNxtQpDFbmzVETt1HbAkwYMjs5w6m0dAtRv58/jdqblffNgV7NQKI+4wCuPjiN2km JsjhDsahSheFwJaK1tsuKPjfUskNnCTI6mhK7DoBzIlos36a2VIC50AUiGxWy6MKKuvE RT23nVhDX+byfUnlIhK0l91ldy1q3nHX7Yl6Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=E0ggTp9P30zbb9pkS6kunzJmTCr4KiA42AuNfYiv7dObcsdNd231lEi4pETsBglO4J kS/nNgQre3ckW5U4NFfD8FMN4IZSwL75Gq+21NHXxa36DFZmh5uCIFga9BbULmZAemCM Hn65WPPs4h6WfoecNkCG1siDW3ej0vt7mq3Xo= MIME-Version: 1.0 Received: by 10.231.154.197 with SMTP id p5mr3050092ibw.28.1264649429143; Wed, 27 Jan 2010 19:30:29 -0800 (PST) Date: Thu, 28 Jan 2010 11:30:29 +0800 Message-ID: <7237120a1001271930g711eb3a3i7ca334c387c2f93f@mail.gmail.com> From: =?GB2312?B?wfW/rQ==?= To: freebsd-net@freebsd.org X-Mailman-Approved-At: Thu, 28 Jan 2010 04:15:01 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: capturing wireless packets of multicast 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, 28 Jan 2010 03:30:30 -0000 hello all: recently I have a problem about capturing wireless packets of multicast. There is the network architecture. Frist, there is a swith which don't support multicast, and then a PC(PC1) and a AP connect the switch. the PC is multicasting. There is another PC(PC2) with wirelss network card to capture wireless packets of multicast via 802.11g. The question came out.I have two wireless network card. One is inter 4965AG, another is atheros AR2425. If PC2 use the intet 4965AG, it can capture the wireless multicast packets, but if it use the atheros one, it can't. So I wonder why the atheros can't. the difference of two wireless card? the network architecture? the switch? Thanks kevin From owner-freebsd-net@FreeBSD.ORG Thu Jan 28 06:07:24 2010 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 917CC106573F for ; Thu, 28 Jan 2010 06:07:24 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id A72718FC2A for ; Thu, 28 Jan 2010 06:07:23 +0000 (UTC) Received: from compute1.internal (compute1.internal [10.202.2.41]) by gateway1.messagingengine.com (Postfix) with ESMTP id 39DD1CDF5C; Thu, 28 Jan 2010 01:07:23 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Thu, 28 Jan 2010 01:07:23 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=message-id:date:from:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; s=smtpout; bh=897v4hdiN313U3zzedTZARLTH5k=; b=VO571P/0T9XLfjKmrR3T1OR3sKZb/NWSBf+e23r9MANjNv0uRCU1ejYnn2Rc57aaKvs+H5AGob9KXP8pr2Hvj6O2GoNLWmfjOwCSUNBR5y6h2GpaF1IpL2hRb6X7rbdQpfKOYNh2JYGG4Ytbb1KkqWM4vnr7xajA80NAbOhL7lo= X-Sasl-enc: BD7z4DGcl3Dr3ICRilSC3Cc89BjlMLGI9FPwjylMbEwM 1264658842 Received: from anglepoise.lon.incunabulum.net (cpc2-dals7-0-0-cust253.hari.cable.virginmedia.com [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id B3D291954D; Thu, 28 Jan 2010 01:07:22 -0500 (EST) Message-ID: <4B612997.8030505@incunabulum.net> Date: Thu, 28 Jan 2010 06:07:19 +0000 From: Bruce Simpson User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.7) Gecko/20100124 Thunderbird/3.0.1 MIME-Version: 1.0 To: =?UTF-8?B?TmF6ZWVtINmG2KzZhSDZhNiv2YrZhg==?= References: <7609d8391001270601m489ab6e6xe956d1539f2cbe4e@mail.gmail.com> In-Reply-To: <7609d8391001270601m489ab6e6xe956d1539f2cbe4e@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: MROUTED: Problem with vif installation 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, 28 Jan 2010 06:07:24 -0000 Did you remember to kldload ip_mroute or build your kernel with 'options MROUTING' ? From owner-freebsd-net@FreeBSD.ORG Thu Jan 28 06:08:38 2010 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 DFC45106568F for ; Thu, 28 Jan 2010 06:08:38 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id AFF248FC0C for ; Thu, 28 Jan 2010 06:08:38 +0000 (UTC) Received: from compute2.internal (compute2.internal [10.202.2.42]) by gateway1.messagingengine.com (Postfix) with ESMTP id 5AFEFCE4D4; Thu, 28 Jan 2010 01:08:38 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute2.internal (MEProxy); Thu, 28 Jan 2010 01:08:38 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=message-id:date:from:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; s=smtpout; bh=5vJM/H/gaXevCes7l9oI2RAiUAQ=; b=bNA9xXZHmeJCeGLoQI/KDZFXs/JlYEnj3KIuyw1hSJf7gP0yBt+7HVvTlpj+L8QIS4IjkTbhWwK6NiArUXhuZ/qSyP3WeUmq9WTbxWYkJpI3GPKvI+D1gp4zXNGOKtmQAg5tI8kIl49qsTJJgUX6HZKfHQuKToBbx0dsOA0Xhag= X-Sasl-enc: PeLE1Qikg+DvM5EwOfHLZRNgF4MgMskVjSKJ5+ZrSKDz 1264658918 Received: from anglepoise.lon.incunabulum.net (cpc2-dals7-0-0-cust253.hari.cable.virginmedia.com [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id E00F01954D; Thu, 28 Jan 2010 01:08:37 -0500 (EST) Message-ID: <4B6129E5.50009@incunabulum.net> Date: Thu, 28 Jan 2010 06:08:37 +0000 From: Bruce Simpson User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.7) Gecko/20100124 Thunderbird/3.0.1 MIME-Version: 1.0 To: Brett Glass References: <201001280126.SAA18331@lariat.net> In-Reply-To: <201001280126.SAA18331@lariat.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Ralink 28xx series drivers? 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, 28 Jan 2010 06:08:39 -0000 On 01/28/10 01:26, Brett Glass wrote: > I am trying to make FreeBSD 8.0 fully functional on an ASUS mini-workstation > that seems to have a Ralink RT2860 card inside. The "ral" driver for FreeBSD > doesn't recognize the card. > > Apparently, OpenBSD does have a driver for this chip. Is anyone porting it? > Please copy me on responses, as I am not a full time subscriber of this list. > moonlightakkiy@yahoo.ca is working on a port of Damien Bergamini's run(4) driver for OpenBSD right now. I can successfully get an RT3071 based Sitecom WL-344 dongle to attach and associate. HostAP mode may take more work. cheers, BMS From owner-freebsd-net@FreeBSD.ORG Thu Jan 28 06:19:42 2010 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 9584E1065670 for ; Thu, 28 Jan 2010 06:19:42 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id 46C6A8FC20 for ; Thu, 28 Jan 2010 06:19:42 +0000 (UTC) Received: from compute1.internal (compute1.internal [10.202.2.41]) by gateway1.messagingengine.com (Postfix) with ESMTP id CF53BCE923; Thu, 28 Jan 2010 01:19:41 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Thu, 28 Jan 2010 01:19:41 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=message-id:date:from:mime-version:to:cc:subject:references:in-reply-to:content-type; s=smtpout; bh=9HOY2GPjB6euI9fRYJ7yy6XcxpI=; b=dSRzpmA2a6rygHMqjcoXhuToN6xUfQUEl43jsf8KUOXU+B7jiPYFuqGMuQsgeG5hUH7c6IZuYEwB8365PN5Q0Q6zu6aIIlnX+GIxFxoOzVT5wOJHKhngeUfpYI/m8WW2kSHrqA+5iT7NSviAebg9DREMCrU3ikrWL02jVBPliuw= X-Sasl-enc: gDfRpWCMC3GLC3O2tWNJQ953pDOqJsKdzTVn0KtGuzRw 1264659580 Received: from anglepoise.lon.incunabulum.net (cpc2-dals7-0-0-cust253.hari.cable.virginmedia.com [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 84A1549B568; Thu, 28 Jan 2010 01:19:40 -0500 (EST) Message-ID: <4B612C79.9010201@incunabulum.net> Date: Thu, 28 Jan 2010 06:19:37 +0000 From: Bruce Simpson User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.7) Gecko/20100124 Thunderbird/3.0.1 MIME-Version: 1.0 To: Brett Glass References: <201001280126.SAA18331@lariat.net> <4B6129E5.50009@incunabulum.net> In-Reply-To: <4B6129E5.50009@incunabulum.net> Content-Type: multipart/mixed; boundary="------------080907070502090003070007" Cc: freebsd-net@FreeBSD.org, moonlightakkiy@yahoo.ca Subject: Re: Ralink 28xx series drivers? 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, 28 Jan 2010 06:19:42 -0000 This is a multi-part message in MIME format. --------------080907070502090003070007 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 01/28/10 06:08, Bruce Simpson wrote: > ... > moonlightakkiy maybe-at yahoo.ca is working on a port of Damien > Bergamini's run(4) driver for OpenBSD right now. I should know better than to cut and paste email addresses in an environment where there may be spam clams. My apologies, Akinori-san. > > I can successfully get an RT3071 based Sitecom WL-344 dongle to attach > and associate. HostAP mode may take more work. I have some diffs to send Akinori as I had to add my dongle to usbdevs. Here they are. I had to manually merge usbdevs as there was quite a bit of drift -- these diffs are against 8-STABLE, so I've attached a hand-merged usbdevs diff against that which includes my device's ID: idVendor = 0x0df6 idProduct = 0x0040 bcdDevice = 0x0101 iManufacturer = 0x0001 iProduct = 0x0002 <802.11 n WLAN> Akinori's code is available from: git://dev.nasreddine.com/run.git cheers, BMS --------------080907070502090003070007 Content-Type: text/plain; name="if_run.c.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="if_run.c.diff" --- sys/dev/usb/wlan/if_run.c.orig 2010-01-26 21:18:18.000000000 +0000 +++ sys/dev/usb/wlan/if_run.c 2010-01-26 21:18:19.000000000 +0000 @@ -234,6 +234,7 @@ { USB_VP(USB_VENDOR_SITECOMEU, USB_PRODUCT_SITECOMEU_RT3070_2) }, { USB_VP(USB_VENDOR_SITECOMEU, USB_PRODUCT_SITECOMEU_RT3070_3) }, { USB_VP(USB_VENDOR_SITECOMEU, USB_PRODUCT_SITECOMEU_RT3070_4) }, + { USB_VP(USB_VENDOR_SITECOMEU, USB_PRODUCT_SITECOMEU_RT3071) }, { USB_VP(USB_VENDOR_SITECOMEU, USB_PRODUCT_SITECOMEU_RT3072_1) }, { USB_VP(USB_VENDOR_SITECOMEU, USB_PRODUCT_SITECOMEU_RT3072_2) }, { USB_VP(USB_VENDOR_SITECOMEU, USB_PRODUCT_SITECOMEU_RT3072_3) }, --------------080907070502090003070007 Content-Type: text/plain; name="usbdevs-fixup.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="usbdevs-fixup.diff" Index: sys/dev/usb/usbdevs =================================================================== --- sys/dev/usb/usbdevs (revision 203039) +++ sys/dev/usb/usbdevs (working copy) @@ -524,6 +524,7 @@ vendor NETAC 0x0dd8 Netac vendor SITECOMEU 0x0df6 Sitecom Europe vendor MOBILEACTION 0x0df7 Mobile Action +vendor AMIGO 0x0e0b Amigo Technology vendor SPEEDDRAGON 0x0e55 Speed Dragon Multimedia vendor HAWKING 0x0e66 Hawking vendor FOSSIL 0x0e67 Fossil, Inc @@ -589,12 +590,14 @@ vendor BALTECH 0x13ad Baltech vendor CISCOLINKSYS 0x13b1 Cisco-Linksys vendor SHARK 0x13d2 Shark +vendor AZUREWAVE 0x13d3 AsureWave vendor EMTEC 0x13fe Emtec vendor NOVATEL 0x1410 Novatel Wireless vendor MERLIN 0x1416 Merlin vendor WISTRONNEWEB 0x1435 Wistron NeWeb vendor RADIOSHACK 0x1453 Radio Shack vendor HUAWEI3COM 0x1472 Huawei-3Com +vendor ABOCOM2 0x1482 AboCom Systems vendor SILICOM 0x1485 Silicom vendor RALINK 0x148f Ralink Technology vendor IMAGINATION 0x149a Imagination Technologies @@ -610,6 +613,7 @@ vendor UMEDIA 0x157e U-MEDIA Communications vendor FIBERLINE 0x1582 Fiberline vendor SPARKLAN 0x15a9 SparkLAN +vendor AMIT2 0x15c5 AMIT vendor SOHOWARE 0x15e8 SOHOware vendor UMAX 0x1606 UMAX Data Systems vendor INSIDEOUT 0x1608 Inside Out Networks @@ -618,6 +622,7 @@ vendor ENTREGA 0x1645 Entrega vendor ACTIONTEC 0x1668 Actiontec Electronics vendor ATHEROS 0x168c Atheros Communications +vendor CISCOLINKSYS2 0x167b Cisco-Linksys vendor GIGASET 0x1690 Gigaset vendor GLOBALSUN 0x16ab Global Sun Technology vendor ANYDATA 0x16d5 AnyDATA Corporation @@ -626,6 +631,8 @@ vendor AXESSTEL 0x1726 Axesstel Co., Ltd. vendor LINKSYS4 0x1737 Linksys vendor SENAO 0x1740 Senao +vendor ASUS2 0x1761 ASUS +vendor SWEEX2 0x177f Sweex vendor METAGEEK 0x1781 MetaGeek vendor AMIT 0x18c5 AMIT vendor QCOM 0x18e8 Qcom @@ -639,9 +646,13 @@ vendor DRESDENELEKTRONIK 0x1cf1 dresden elektronik vendor QISDA 0x1da5 Qisda vendor ALINK 0x1e0e Alink +vendor PEGATRON 0x1d4d Pegatron +vendor AIRTIES 0x1eda AirTies vendor DLINK 0x2001 D-Link vendor PLANEX2 0x2019 Planex Communications vendor TLAYTECH 0x20b9 Tlay Tech +vendor ENCORE 0x203d Encore +vendor PARA 0x20b8 PARA Industrial vendor ERICSSON 0x2282 Ericsson vendor MOTOROLA2 0x22b8 Motorola vendor TRIPPLITE 0x2478 Tripp-Lite @@ -667,6 +678,7 @@ vendor SITECOM 0x6189 Sitecom vendor ARKMICRO 0x6547 Arkmicro Technologies Inc. vendor 3COM2 0x6891 3Com +vendor EDIMAX 0x7392 EDIMAX vendor INTEL 0x8086 Intel vendor INTEL2 0x8087 Intel vendor SITECOM2 0x9016 Sitecom @@ -701,6 +713,12 @@ /* AboCom products */ product ABOCOM XX1 0x110c XX1 product ABOCOM XX2 0x200c XX2 +product ABOCOM RT2770 0x2770 RT2770 +product ABOCOM RT2870 0x2870 RT2870 +product ABOCOM RT3070 0x3070 RT3070 +product ABOCOM RT3071 0x3071 RT3071 +product ABOCOM RT3072 0x3072 RT3072 +product ABOCOM2 RT2870_1 0x3c09 RT2870 product ABOCOM URE450 0x4000 URE450 Ethernet Adapter product ABOCOM UFE1000 0x4002 UFE1000 Fast Ethernet Adapter product ABOCOM DSB650TX_PNA 0x4003 1/10/100 Ethernet Adapter @@ -731,6 +749,17 @@ product ACCTON SMCWUSBTG2 0x4508 SMCWUSBT-G2 product ACCTON PRISM_GT 0x4521 PrismGT USB 2.0 WLAN product ACCTON SS1001 0x5046 SpeedStream Ethernet Adapter +product ACCTON RT2870_2 0x6618 RT2870 +product ACCTON RT3070 0x7511 RT3070 +product ACCTON RT2770 0x7512 RT2770 +product ACCTON RT2870_3 0x7522 RT2870 +product ACCTON RT2870_5 0x8522 RT2870 +product ACCTON RT3070_4 0xa512 RT3070 +product ACCTON RT2870_4 0xa618 RT2870 +product ACCTON RT3070_1 0xa701 RT3070 +product ACCTON RT3070_2 0xa702 RT3070 +product ACCTON RT2870_1 0xb522 RT2870 +product ACCTON RT3070_3 0xc522 RT3070 product ACCTON ZD1211B 0xe501 ZD1211B /* Aceeca products */ @@ -833,6 +862,9 @@ /* AirPrime products */ product AIRPRIME PC5220 0x0112 CDMA Wireless PC Card +/* AirTies products */ +product AIRTIES RT3070 0x2310 RT3070 + /* AKS products */ product AKS USBHASP 0x0001 USB-HASP 0.06 @@ -872,9 +904,21 @@ product AMBIT WLAN 0x0302 WLAN product AMBIT NTL_250 0x6098 NTL 250 cable modem +/* American Power Conversion products */ +product APC UPS 0x0002 Uninterruptible Power Supply + +/* Amigo Technology products */ +product AMIGO RT2870_1 0x9031 RT2870 +product AMIGO RT2870_2 0x9041 RT2870 + /* AMIT products */ product AMIT CGWLUSB2GO 0x0002 CG-WLUSB2GO +product AMIT CGWLUSB2GNR 0x0008 CG-WLUSB2GNR +product AMIT RT2870_1 0x0012 RT2870 +/* AMIT(2) products */ +product AMIT2 RT2870 0x0008 RT2870 + /* Anchor products */ product ANCHOR EZUSB 0x2131 EZUSB product ANCHOR EZLINK 0x2720 EZLINK @@ -933,6 +977,7 @@ product ASIX AX88772A 0x772a AX88772A USB 2.0 10/100 Ethernet /* ASUS products */ +product ASUS2 USBN11 0x0b05 USB-N11 product ASUS WL167G 0x1707 WL-167g Wireless Adapter product ASUS WL159G 0x170c WL-159g product ASUS A9T_WIFI 0x171b A9T wireless @@ -940,6 +985,12 @@ product ASUS RT2573_1 0x1723 RT2573 product ASUS RT2573_2 0x1724 RT2573 product ASUS LCM 0x1726 LCM display +product ASUS RT2870_1 0x1731 RT2870 +product ASUS RT2870_2 0x1732 RT2870 +product ASUS RT2870_3 0x1742 RT2870 +product ASUS RT2870_4 0x1760 RT2870 +product ASUS RT2870_5 0x1761 RT2870 +product ASUS RT3070 0x1784 RT3070 product ASUS P535 0x420f ASUS P535 PDA product ASUS GMSC 0x422f ASUS Generic Mass Storage product ASUS RT2570 0x1706 RT2500USB Wireless Adapter @@ -976,6 +1027,13 @@ /* Axesstel products */ product AXESSTEL DATAMODEM 0x1000 Data Modem +/* AsureWave products */ +product AZUREWAVE RT2870_1 0x3247 RT2870 +product AZUREWAVE RT2870_2 0x3262 RT2870 +product AZUREWAVE RT3070_1 0x3273 RT3070 +product AZUREWAVE RT3070_2 0x3284 RT3070 +product AZUREWAVE RT3070_3 0x3305 RT3070 + /* Baltech products */ product BALTECH CARDREADER 0x9999 Card reader @@ -1006,8 +1064,13 @@ /* Also sold as 'Ativa 802.11g wireless card' */ product BELKIN F5D7050_V4000 0x705c F5D7050 v4000 Wireless Adapter product BELKIN F5D7050E 0x705e F5D7050E Wireless Adapter +product BELKIN RT2870_1 0x8053 RT2870 +product BELKIN RT2870_2 0x805c RT2870 +product BELKIN F5D8053V3 0x815c F5D8053 v3 +product BELKIN F5D8055 0x825a F5D8055 product BELKIN F5D9050V3 0x905b F5D9050 ver 3 Wireless Adapter product BELKIN2 F5U002 0x0002 F5U002 Parallel printer +product BELKIN F6D4050V1 0x935a F6D4050 ver 1 /* Billionton products */ product BILLIONTON USB100 0x0986 USB100N 10/100 FastEthernet @@ -1084,6 +1147,7 @@ product CISCOLINKSYS WUSB54GC 0x0020 WUSB54GC product CISCOLINKSYS WUSB54GR 0x0023 WUSB54GR product CISCOLINKSYS WUSBF54G 0x0024 WUSBF54G +product CISCOLINKSYS2 RT3070 0x4001 RT3070 /* CMOTECH products */ product CMOTECH CNU510 0x5141 CDMA Technologies USB modem @@ -1110,6 +1174,15 @@ product CONCEPTRONIC AR5523_2_NF 0x7812 AR5523 (no firmware) product CONCEPTRONIC2 C54RU 0x3c02 C54RU WLAN product CONCEPTRONIC2 C54RU2 0x3c22 C54RU +product CONCEPTRONIC2 VIGORN61 0x3c25 VIGORN61 +product CONCEPTRONIC2 RT2870_1 0x3c06 RT2870 +product CONCEPTRONIC2 RT2870_2 0x3c07 RT2870 +product CONCEPTRONIC2 RT2870_7 0x3c09 RT2870 +product CONCEPTRONIC2 RT2870_8 0x3c12 RT2870 +product CONCEPTRONIC2 RT2870_3 0x3c23 RT2870 +product CONCEPTRONIC2 RT2870_4 0x3c25 RT2870 +product CONCEPTRONIC2 RT2870_5 0x3c27 RT2870 +product CONCEPTRONIC2 RT2870_6 0x3c28 RT2870 /* Connectix products */ product CONNECTIX QUICKCAM 0x0001 QuickCam @@ -1124,6 +1197,11 @@ product COREGA WLUSB_11_KEY 0x001a ULUSB-11 Key product COREGA CGWLUSB2GL 0x002d CG-WLUSB2GL product COREGA CGWLUSB2GPX 0x002e CG-WLUSB2GPX +product COREGA RT2870_1 0x002f RT2870 +product COREGA RT2870_2 0x003c RT2870 +product COREGA RT2870_3 0x003f RT2870 +product COREGA RT3070 0x0041 RT3070 +product COREGA CGWLUSB300GNM 0x0042 CG-WLUSB300GNM product COREGA WLUSB_11_STICK 0x7613 WLAN USB Stick 11 product COREGA FETHER_USB_TXC 0x9601 FEther USB-TXC @@ -1152,6 +1230,7 @@ /* CyberTAN Technology products */ product CYBERTAN TG54USB 0x1666 TG54USB +product CYBERTAN RT2870 0x1828 RT2870 /* Cypress Semiconductor products */ product CYPRESS MOUSE 0x0001 mouse @@ -1229,6 +1308,8 @@ product DLINK DWLAG122_NF 0x3a05 DWL-AG122 (no firmware) product DLINK DWLG122 0x3c00 DWL-G122 b1 Wireless Adapter product DLINK DUBE100B1 0x3c05 DUB-E100 rev B1 +product DLINK RT2870 0x3c09 RT2870 +product DLINK RT3072 0x3c0a RT3072 product DLINK DSB650C 0x4000 10Mbps Ethernet product DLINK DSB650TX1 0x4001 10/100 Ethernet product DLINK DSB650TX 0x4002 10/100 Ethernet @@ -1241,8 +1322,16 @@ product DLINK2 DWLG122C1 0x3c03 DWL-G122 c1 product DLINK2 WUA1340 0x3c04 WUA-1340 product DLINK2 DWA111 0x3c06 DWA-111 +product DLINK2 RT2870_1 0x3c09 RT2870 product DLINK2 DWA110 0x3c07 DWA-110 product DLINK3 DWM652 0x3e04 DWM-652 +product DLINK2 RT3072 0x3c0a RT3072 +product DLINK2 RT3070_1 0x3c0d RT3070 +product DLINK2 RT3070_2 0x3c0e RT3070 +product DLINK2 RT3070_3 0x3c0f RT3070 +product DLINK2 RT2870_2 0x3c11 RT2870 +product DLINK2 DWA130 0x3c13 DWA-130 +product DLINK2 RT3070_4 0x3c15 RT3070 /* DMI products */ product DMI CFSM_RW 0xa109 CF/SM Reader/Writer @@ -1260,6 +1349,11 @@ /* Eicon Networks */ product EICON DIVA852 0x4905 Diva 852 ISDN TA +/* EDIMAX products */ +product EDIMAX RT2870_1 0x7711 RT2870 +product EDIMAX EW7717 0x7717 EW-7717 +product EDIMAX EW7718 0x7718 EW-7718 + /* EIZO products */ product EIZO HUB 0x0000 hub product EIZO MONITOR 0x0001 monitor @@ -1285,6 +1379,11 @@ /* EMS products */ product EMS DUAL_SHOOTER 0x0003 PSX gun controller converter +/* Encore products */ +product ENCORE RT3070_1 0x1480 RT3070 +product ENCORE RT3070_2 0x14a1 RT3070 +product ENCORE RT3070_3 0x14a9 RT3070 + /* Entrega products */ product ENTREGA 1S 0x0001 1S serial product ENTREGA 2S 0x0002 2S serial @@ -1429,6 +1528,11 @@ product GIGASET AR5523 0x0712 AR5523 product GIGASET AR5523_NF 0x0713 AR5523 (no firmware) product GIGASET RT2573 0x0722 RT2573 +product GIGASET RT3070_1 0x0740 RT3070 +product GIGASET RT3070_2 0x0744 RT3070 +product GIGABYTE RT2870_1 0x800b RT2870 +product GIGABYTE GNWB31N 0x800c GN-WB31N +product GIGABYTE GNWB32L 0x800d GN-WB32L /* Global Sun Technology product */ product GLOBALSUN AR5523_1 0x7801 AR5523 @@ -1464,6 +1568,7 @@ product GUILLEMOT HWGUSB254 0xe000 HWGUSB2-54 WLAN product GUILLEMOT HWGUSB254LB 0xe010 HWGUSB2-54-LB product GUILLEMOT HWGUSB254V2AP 0xe020 HWGUSB2-54V2-AP +product GUILLEMOT HWNU300 0xe030 HWNU-300 /* Hagiwara products */ product HAGIWARA FGSM 0x0002 FlashGate SmartMedia Card Reader @@ -1482,6 +1587,10 @@ product HAUPPAUGE WINTV_USB_FM 0x4d12 WinTV USB FM /* Hawking Technologies products */ +product HAWKING RT2870_1 0x0001 RT2870 +product HAWKING RT2870_2 0x0003 RT2870 +product HAWKING HWUN2 0x0009 HWUN2 +product HAWKING RT3070 0x000b RT3070 product HAWKING UF100 0x400c 10/100 USB Ethernet /* Hitachi, Ltd. products */ @@ -1528,6 +1637,7 @@ product HP 568J 0x1116 Jornada 568 product HP 930C 0x1204 DeskJet 930c product HP P2000U 0x1801 Inkjet P-2000U +product HP HS2300 0x1e1d HS2300 HSDPA (aka MC8775) product HP 640C 0x2004 DeskJet 640c product HP 4670V 0x3005 ScanJet 4670v product HP P1100 0x3102 Photosmart P1100 @@ -1655,6 +1765,10 @@ product IODATA USBWNB11A 0x0919 USB WN-B11 product IODATA USBWNB11 0x0922 USB Airport WN-B11 product IODATA ETGUS2 0x0930 ETG-US2 +product IODATA RT3072_1 0x0944 RT3072 +product IODATA RT3072_2 0x0945 RT3072 +product IODATA RT3072_3 0x0947 RT3072 +product IODATA RT3072_4 0x0948 RT3072 product IODATA USBRSAQ 0x0a03 Serial USB-RSAQ1 product IODATA2 USB2SC 0x0a09 USB2.0-SCSI Bridge USB2-SC @@ -1779,7 +1893,11 @@ product LINKSYS2 USB200M 0x2226 USB 2.0 10/100 Ethernet product LINKSYS3 WUSB11v28 0x2233 WUSB11 v2.8 Wireless Adapter product LINKSYS4 USB1000 0x0039 USB1000 +product LINKSYS4 WUSB100 0x0070 WUSB100 +product LINKSYS4 WUSB600N 0x0071 WUSB600N product LINKSYS4 WUSB54GCV2 0x0073 WUSB54GC v2 +product LINKSYS4 WUSB54GCV3 0x0077 WUSB54GC v3 +product LINKSYS4 WUSB600NV2 0x0079 WUSB600N v2 /* Logitech products */ product LOGITECH M2452 0x0203 M2452 keyboard @@ -1797,6 +1915,9 @@ product LOGITECH BD58 0xc00c BD58 mouse product LOGITECH UN58A 0xc030 iFeel Mouse product LOGITECH UN53B 0xc032 iFeel MouseMan +product LOGITEC RT2870_1 0x0162 RT2870 +product LOGITEC RT2870_2 0x0163 RT2870 +product LOGITEC RT2870_3 0x0164 RT2870 product LOGITECH WMPAD 0xc208 WingMan GamePad Extreme product LOGITECH WMRPAD 0xc20a WingMan RumblePad product LOGITECH WMJOY 0xc281 WingMan Force joystick @@ -1846,7 +1967,10 @@ product MELCO SG54HP 0x00d8 WLI-U2-SG54HP product MELCO G54HP 0x00d9 WLI-U2-G54HP product MELCO KG54L 0x00da WLI-U2-KG54L +product MELCO WLIUCG300N 0x00e8 WLI-UC-G300N product MELCO SG54HG 0x00f4 WLI-U2-SG54HG +product MELCO WLIUCAG300N 0x012e WLI-UC-AG300N +product MELCO WLIUCGN 0x015d WLI-UC-GN /* Merlin products */ product MERLIN V620 0x1110 Merlin V620 @@ -1864,15 +1988,25 @@ /* Micro Star International products */ product MSI BT_DONGLE 0x1967 Bluetooth USB dongle +product MSI RT3070_1 0x3820 RT3070 +product MSI RT3070_2 0x3821 RT3070 +product MSI RT3070_3 0x3870 RT3070 product MSI UB11B 0x6823 UB11B product MSI RT2570 0x6861 RT2570 product MSI RT2570_2 0x6865 RT2570 product MSI RT2570_3 0x6869 RT2570 product MSI RT2573_1 0x6874 RT2573 product MSI RT2573_2 0x6877 RT2573 +product MSI RT3070_4 0x6899 RT3070 +product MSI RT3070_5 0x821a RT3070 product MSI RT2573_3 0xa861 RT2573 +product MSI RT3070_6 0x870a RT3070 +product MSI RT3070_7 0x899a RT3070 product MSI RT2573_4 0xa874 RT2573 +/* Microdia products */ +product MICRODIA TWINKLECAM 0x600d TwinkleCam USB camera + /* Microsoft products */ product MICROSOFT SIDEPREC 0x0008 SideWinder Precision Pro product MICROSOFT INTELLIMOUSE 0x0009 IntelliMouse @@ -2017,6 +2151,9 @@ product NIKON LS40 0x4000 CoolScan LS40 ED product NIKON D300 0x041a Digital Camera D300 +/* Nokia products */ +product NOKIA N958GB 0x0070 Nokia N95 8GBc + /* NovaTech Products */ product NOVATECH NV902 0x9020 NovaTech NV-902W product NOVATECH RT2573 0x9021 RT2573 @@ -2140,6 +2277,14 @@ product PANASONIC KXLCB35AN 0x0d0e DVD-ROM & CD-R/RW product PANASONIC SDCAAE 0x1b00 MultiMediaCard +/* PARA Industrial products */ +product PARA RT3070 0x8888 RT3070 + +/* Pegatron products */ +product PEGATRON RT2870 0x0002 RT2870 +product PEGATRON RT3070 0x000c RT3070 +product PEGATRON RT3070_2 0x000e RT3070 + /* Peracom products */ product PERACOM SERIAL1 0x0001 Serial product PERACOM ENET 0x0002 Ethernet @@ -2157,12 +2302,14 @@ product PHILIPS SNU5600 0x1236 SNU5600 product PHILIPS UM10016 0x1552 ISP 1581 Hi-Speed USB MPEG2 Encoder Reference Kit product PHILIPS DIVAUSB 0x1801 DIVA USB mp3 player +product PHILIPS RT2870 0x200f RT2870 /* Philips Semiconductor products */ product PHILIPSSEMI HUB1122 0x1122 HUB /* Megatec */ product MEGATEC UPS 0x5161 Protocol based UPS +product PHILIPSSEMI HUB1122 0x1122 hub /* P.I. Engineering products */ product PIENGINEERING PS2USB 0x020b PS2 to Mac USB Adapter @@ -2172,11 +2319,15 @@ product PLANEX2 GW_US11S 0x3220 GW-US11S WLAN product PLANEX2 GW_US54GXS 0x5303 GW-US54GXS WLAN product PLANEX2 GWUS54HP 0xab01 GW-US54HP +product PLANEX2 GWUS300MINIS 0xab24 GW-US300MiniS +product PLANEX2 RT3070 0xab25 RT3070 product PLANEX2 GWUS54MINI2 0xab50 GW-US54Mini2 product PLANEX2 GWUS54SG 0xc002 GW-US54SG product PLANEX2 GWUS54GZL 0xc007 GW-US54GZL product PLANEX2 GWUS54GD 0xed01 GW-US54GD product PLANEX2 GWUSMM 0xed02 GW-USMM +product PLANEX2 RT2870 0xed06 RT2870 +product PLANEX2 GWUSMICRON 0xed14 GW-USMicroN product PLANEX3 GWUS54GZ 0xab10 GW-US54GZ product PLANEX3 GU1000T 0xab11 GU-1000T product PLANEX3 GWUS54MINI 0xab13 GW-US54Mini @@ -2240,6 +2391,7 @@ product QISDA H21_2 0x4523 3G modem product QISDA H20_1 0x4515 3G modem product QISDA H20_2 0x4519 3G modem +product QCOM RT2870 0x6259 RT2870 /* Qualcomm products */ product QUALCOMM CDMA_MSM 0x6000 CDMA Technologies MSM phone @@ -2329,6 +2481,9 @@ /* Qtronix products */ product QTRONIX 980N 0x2011 Scorpion-980N keyboard +/* Quanta products */ +product QUANTA RT3070 0x0304 RT3070 + /* Quickshot products */ product QUICKSHOT STRIKEPAD 0x6238 USB StrikePad @@ -2340,9 +2495,16 @@ /* Ralink Technology products */ product RALINK RT2570 0x1706 RT2500USB Wireless Adapter +product RALINK RT2070 0x2070 RT2070 product RALINK RT2570_2 0x2570 RT2500USB Wireless Adapter product RALINK RT2573 0x2573 RT2501USB Wireless Adapter product RALINK RT2671 0x2671 RT2601USB Wireless Adapter +product RALINK RT2770 0x2770 RT2770 +product RALINK RT2870 0x2870 RT2870 +product RALINK RT3070 0x3070 RT3070 +product RALINK RT3071 0x3071 RT3071 +product RALINK RT3072 0x3072 RT3072 +product RALINK RT3572 0x3572 RT3572 product RALINK RT2570_3 0x9020 RT2500USB Wireless Adapter product RALINK RT2573_2 0x9021 RT2501USB Wireless Adapter @@ -2383,6 +2545,7 @@ product SAMSUNG ML6060 0x3008 ML-6060 laser printer product SAMSUNG YP_U2 0x5050 YP-U2 MP3 Player product SAMSUNG I500 0x6601 I500 Palm USB Phone +product SAMSUNG2 RT2870_1 0x2018 RT2870 /* Samsung Techwin products */ product SAMSUNG_TECHWIN DIGIMAX_410 0x000a Digimax 410 @@ -2406,7 +2569,18 @@ product SCANLOGIC 336CX 0x0300 Phantom 336CX - C3 scanner /* Senao products */ +product SENAO RT2870_3 0x0605 RT2870 +product SENAO RT2870_4 0x0615 RT2870 product SENAO NUB8301 0x2000 NUB-8301 +product SENAO RT2870_1 0x9701 RT2870 +product SENAO RT2870_2 0x9702 RT2870 +product SENAO RT3070 0x9703 RT3070 +product SENAO RT3071 0x9705 RT3071 +product SENAO RT3072_1 0x9706 RT3072 +product SENAO RT3072_2 0x9707 RT3072 +product SENAO RT3072_3 0x9708 RT3072 +product SENAO RT3072_4 0x9709 RT3072 +product SENAO RT3072_5 0x9801 RT3072 /* ShanTou products */ product SHANTOU ST268 0x0268 ST268 @@ -2465,7 +2639,18 @@ product SIERRA E0029 0x0029 E0029 product SIERRA AIRCARD580 0x0112 Sierra Wireless AirCard 580 product SIERRA AC595U 0x0120 Sierra Wireless AirCard 595U +product SIERRA AC875 0x6820 Sierra Wireless AirCard 875 +product SIERRA AC880 0x6850 Sierra Wireless AirCard 880 +product SIERRA AC881 0x6851 Sierra Wireless AirCard 881 +product SIERRA AC880E 0x6852 Sierra Wireless AirCard 880E +product SIERRA AC881E 0x6853 Sierra Wireless AirCard 881E +product SIERRA AC880U 0x6855 Sierra Wireless AirCard 880U +product SIERRA AC881U 0x6856 Sierra Wireless AirCard 881U +product SIERRA AC885U 0x6880 Sierra Wireless AirCard 885U +product SIERRA EM5625 0x0017 EM5625 product SIERRA MC5720 0x0218 MC5720 Wireless Modem +product SIERRA MC5720_2 0x0018 MC5720 +product SIERRA MC5725 0x0020 MC5725 product SIERRA MINI5725 0x0220 Sierra Wireless miniPCI 5275 product SIERRA MC5727_2 0x0224 MC5727 product SIERRA MC8755_2 0x6802 MC8755 @@ -2481,6 +2666,7 @@ product SIERRA AC875 0x6820 Sierra Wireless AirCard 875 product SIERRA AC875U_2 0x6821 AC875U product SIERRA AC875E 0x6822 AC875E +product SIERRA AIRCARD875 0x6820 Aircard 875 HSDPA product SIERRA MC8780 0x6832 MC8780 product SIERRA MC8781 0x6833 MC8781 product SIERRA MC8780_2 0x6834 MC8780 @@ -2554,7 +2740,24 @@ /* Sitecom Europe products */ product SITECOMEU WL168V1 0x000d WL-168 v1 +product SITECOMEU RT2870_1 0x0017 RT2870 product SITECOMEU WL168V4 0x0028 WL-168 v4 +product SITECOMEU RT2870_2 0x002b RT2870 +product SITECOMEU RT2870_3 0x002c RT2870 +product SITECOMEU RT2870_4 0x002d RT2870 +product SITECOMEU RT2770 0x0039 RT2770 +product SITECOMEU RT3070_2 0x003b RT3070 +product SITECOMEU RT3070_3 0x003c RT3070 +product SITECOMEU RT3070_4 0x003d RT3070 +product SITECOMEU RT3070 0x003e RT3070 +product SITECOMEU WL608 0x003f WL-608 +product SITECOMEU RT3071 0x0040 RT3071 +product SITECOMEU RT3072_1 0x0041 RT3072 +product SITECOMEU RT3072_2 0x0042 RT3072 +product SITECOMEU RT3072_3 0x0047 RT3072 +product SITECOMEU RT3072_4 0x0048 RT3072 +product SITECOMEU RT3072_5 0x004a RT3072 +product SITECOMEU RT3072_6 0x004d RT3072 product SITECOMEU LN028 0x061c LN-028 product SITECOMEU WL113 0x9071 WL-113 product SITECOMEU ZD1211B 0x9075 ZD1211B @@ -2613,6 +2816,8 @@ /* SparkLAN products */ product SPARKLAN RT2573 0x0004 RT2573 +product SPARKLAN RT2870_1 0x0006 RT2870 +product SPARKLAN RT3070 0x0010 RT3070 /* Sphairon Access Systems GmbH products */ product SPHAIRON UB801R 0x0110 UB801R @@ -2682,6 +2887,8 @@ /* Sweex products */ product SWEEX ZD1211 0x1809 ZD1211 +product SWEEX2 LW303 0x0302 LW303 +product SWEEX2 LW313 0x0313 LW313 /* System TALKS, Inc. */ product SYSTEMTALKS SGCX2UL 0x1920 SGC-X2UL @@ -2775,6 +2982,7 @@ product UMEDIA TEW429UB_A 0x300a TEW-429UB_A product UMEDIA TEW429UB 0x300b TEW-429UB product UMEDIA TEW429UBC1 0x300d TEW-429UB C1 +product UMEDIA RT2870_1 0x300e RT2870 product UMEDIA ALL0298V2 0x3204 ALL0298 v2 product UMEDIA AR5523_2 0x3205 AR5523 product UMEDIA AR5523_2_NF 0x3206 AR5523 (no firmware) @@ -2884,9 +3092,16 @@ product ZCOM AR5523_NF 0x0013 AR5523 driver (no firmware) product ZCOM XM142 0x0015 XM-142 product ZCOM ZD1211B 0x001a ZD1211B +product ZCOM RT2870_1 0x0022 RT2870 +product ZCOM RT2870_2 0x0025 RT2870 /* Zinwell products */ product ZINWELL RT2570 0x0260 RT2570 +product ZINWELL RT2870_1 0x0280 RT2870 +product ZINWELL RT2870_2 0x0282 RT2870 +product ZINWELL RT3072_1 0x0283 RT3072 +product ZINWELL RT3072_2 0x0284 RT3072 +product ZINWELL RT3070 0x5257 RT3070 /* Zoom Telephonics, Inc. products */ product ZOOM 2986L 0x9700 2986L Fax modem @@ -2907,3 +3122,4 @@ product ZYXEL M202 0x340a M-202 product ZYXEL G220V2 0x340f G-220 v2 product ZYXEL G202 0x3410 G-202 +product ZYXEL RT2870_1 0x3416 RT2870 --------------080907070502090003070007-- From owner-freebsd-net@FreeBSD.ORG Thu Jan 28 07:23:12 2010 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 A7931106566B for ; Thu, 28 Jan 2010 07:23:12 +0000 (UTC) (envelope-from nazeemnss@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5B9348FC13 for ; Thu, 28 Jan 2010 07:23:12 +0000 (UTC) Received: by vws18 with SMTP id 18so209567vws.13 for ; Wed, 27 Jan 2010 23:23:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=6p+e2mqLz5EDS9XBF0T9FS+Myuf7ht2s/NUU6qnPZYM=; b=hvYuMYsslKyeYOp/yxWYQXUrZxuZCxFH5TFepCPDerI0t0aKamBL6CA1MA2moTHMLa rYH2mHOPFc2wfJS/Khr6bpd+e0A8wnOZNG5xpmSo0fPXZNJWxZevi+1MhkdzdcrLIQ08 obUdisL12huRd3WbKh6SCx+ln+ry8O6YlFxiQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=NsR2FX7zxjbLwr1uucg7qofO5eWEavczessqv+YoMC8Mx0HXgs9go+liSbMWOg2FwK eckMoOnR/NB+GZqvGxG9hqNxyecfviSsgS7Ij2Nyoa1TvO+BqiOKWRlfc9LnhE0Lhm9r cLcWR+T6S/T6X3JJv2Y6TLsKdUdFEwLDvuqwA= MIME-Version: 1.0 Received: by 10.220.122.97 with SMTP id k33mr4053799vcr.35.1264663387597; Wed, 27 Jan 2010 23:23:07 -0800 (PST) In-Reply-To: <4B612997.8030505@incunabulum.net> References: <7609d8391001270601m489ab6e6xe956d1539f2cbe4e@mail.gmail.com> <4B612997.8030505@incunabulum.net> Date: Thu, 28 Jan 2010 12:53:07 +0530 Message-ID: <7609d8391001272323qa8694c0q9c716fc2e577eb47@mail.gmail.com> From: =?UTF-8?B?TmF6ZWVtINmG2KzZhSDZhNiv2YrZhg==?= To: Bruce Simpson Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: MROUTED: Problem with vif installation 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, 28 Jan 2010 07:23:12 -0000 I have build the kernel with MROUTING option. Cause without it mrouted does not execute. But is this a problem with the tunnel creation as it says setsockopt MRT_ADD_VIF operation not permitted. The machine I use has 2 NICs. I have also enabled gateway "YES". I am trying to setup a multicast tunnel using mrouted. Anything I am missing or gone wrong? Is a tunnel to be setup in some other way first? -Nazeem On Thu, Jan 28, 2010 at 11:37 AM, Bruce Simpson wrote: > Did you remember to kldload ip_mroute or build your kernel with 'options > MROUTING' ? > From owner-freebsd-net@FreeBSD.ORG Thu Jan 28 07:48:24 2010 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 129B6106566B for ; Thu, 28 Jan 2010 07:48:24 +0000 (UTC) (envelope-from nazeemnss@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id B875E8FC13 for ; Thu, 28 Jan 2010 07:48:23 +0000 (UTC) Received: by vws18 with SMTP id 18so221924vws.13 for ; Wed, 27 Jan 2010 23:48:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=qcJJCs3l6sJ99W1W9EKwUTLNLxsk2kTZD548jN/gcDw=; b=OUqagMt/RidPA+y+LZOSvWYnjzL65oasiMyX6pHQDeNVfqkhS8lsBsSyMqEl7xMHTp H9c6iNy99ULx8dwsk8tj/O3FzO4Q2cg6u2zxozk6iQnKSB6564xA/z67f3y7HZPHDiPZ rU7uRfxnnctE0oz+RFgUwa0HbBv5CTuUPUy0c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=gJseRq7RjlR+v9R7w8K7MOo5K0gXosL1v4T+IxIGdGHV9K6LnYETcNf9ipTlYV+Fdm QYxyMfJtBsMCez3YEkVXMvnAo1hekwHjxP9qETIq3VnLfCG7IWF+9XwGDtY4z+KR169n kEecypDccdld0rZC1Py0IyM64tc3RTCkh3WNg= MIME-Version: 1.0 Received: by 10.220.122.24 with SMTP id j24mr1734071vcr.28.1264664902858; Wed, 27 Jan 2010 23:48:22 -0800 (PST) In-Reply-To: <7609d8391001272323qa8694c0q9c716fc2e577eb47@mail.gmail.com> References: <7609d8391001270601m489ab6e6xe956d1539f2cbe4e@mail.gmail.com> <4B612997.8030505@incunabulum.net> <7609d8391001272323qa8694c0q9c716fc2e577eb47@mail.gmail.com> Date: Thu, 28 Jan 2010 13:18:22 +0530 Message-ID: <7609d8391001272348m624201aco31f9a9ff2b3eb4e6@mail.gmail.com> From: =?UTF-8?B?TmF6ZWVtINmG2KzZhSDZhNiv2YrZhg==?= To: Bruce Simpson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: MROUTED: Problem with vif installation 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, 28 Jan 2010 07:48:24 -0000 *GIVING MORE DETAILS:- ifconfig gives:* em0: flags=3D8843 metric 0 mtu 1500 options=3D19b ether 00:1c:c0:00:d6:68 inet 10.129.86.154 netmask 0xffff0000 broadcast 10.129.255.255 media: Ethernet autoselect (100baseTX ) status: active fxp0: flags=3D8843 metric 0 mtu 150= 0 options=3D2009 ether 00:a9:40:0f:47:2f inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255 media: Ethernet autoselect (none) status: no carrier fwe0: flags=3D8802 metric 0 mtu 1500 options=3D8 ether 02:90:27:ef:72:9f ch 1 dma -1 fwip0: flags=3D8802 metric 0 mtu 1500 lladdr 0.90.27.0.1.ef.72.9f.a.2.ff.fe.0.0.0.0 plip0: flags=3D8810 metric 0 mtu 1500 lo0: flags=3D8049 metric 0 mtu 16384 options=3D3 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x6 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 *mrouted.conf * tunnel 10.129.86.154 10.12.11.105 * mrouted -d gives:* freebsd1# mrouted -d debug level 0x2de (pruning,routing,peers,cache,interface,membership,igmp) 13:17:13.980 mrouted version 3.9-beta3+IOS12 starting 13:17:13.980 Getting vifs from kernel interfaces 13:17:13.980 installing em0 (10.129.86.154 on subnet 10.129/16) as vif #0 - rate=3D0 13:17:13.980 installing fxp0 (192.168.0.1 on subnet 192.168.0/24) as vif #1 - rate=3D0 13:17:13.980 Getting vifs from /etc/mrouted.conf 13:17:13.980 installing tunnel from 10.129.86.154 to 10.12.11.105 as vif #2 - rate=3D0 13:17:13.980 Installing vifs in mrouted... 13:17:13.981 vif #0, phyint 10.129.86.154 13:17:13.981 assuming querier duties on vif 0 13:17:13.981 sending query on vif 0 13:17:13.981 SENT membership query from 10.129.86.154 to 224.0.0.1 13:17:13.981 SENT neighbor probe from 10.129.86.154 to 224.0.0.4 13:17:13.981 vif #1, phyint 192.168.0.1 13:17:13.982 assuming querier duties on vif 1 13:17:13.982 sending query on vif 1 13:17:13.982 SENT membership query from 192.168.0.1 to 224.0.0.1 13:17:13.982 SENT neighbor probe from 192.168.0.1 to 224.0.0.4 13:17:13.982 vif #2, tunnel 10.129.86.154 -> 10.12.11.105 13:17:13.982 SENT neighbor probe from 10.129.86.154 to 10.12.11.105 vifs_with_neighbors =3D 0 Virtual Interface Table Vif Name Local-Address M Thr Rate Flags 0 em0 10.129.86.154 subnet: 10.129/16 1 1 0 querier IGMP querier: 10.129.86.154 (this system) Nbr bitmaps: 0x0000000000000000 1 fxp0 192.168.0.1 subnet: 192.168.0/24 1 1 0 querier IGMP querier: 192.168.0.1 (this system) Nbr bitmaps: 0x0000000000000000 2 em0 10.129.86.154 tunnel: 10.12.11.105 1 1 0 rexmit_prunes old-tunnel Nbr bitmaps: 0x0000000000000000 Multicast Routing Table (2 entries) Origin-Subnet From-Gateway Metric Tmr Fl In-Vif Out-Vifs 192.168.0/24 1 0 C. 1 0* 10.129/16 1 0 C. 0 1* 13:17:19.211 aging forwarding cache entries 13:17:19.211 sending query on vif 0 13:17:19.211 SENT membership query from 10.129.86.154 to 224.0.0.1 13:17:19.211 sending query on vif 1 13:17:19.211 SENT membership query from 192.168.0.1 to 224.0.0.1 13:17:19.211 SENT neighbor probe from 10.129.86.154 to 224.0.0.4 13:17:19.211 SENT neighbor probe from 192.168.0.1 to 224.0.0.4 13:17:19.211 SENT neighbor probe from 10.129.86.154 to 10.12.11.105 13:17:24.440 mrouted version 3.9-beta3+IOS12 13:17:24.440 Installing vifs in kernel... 13:17:24.440 vif #0, phyint 10.129.86.154 13:17:24.440 vif #1, phyint 192.168.0.1 13:17:24.440 vif #2, tunnel 10.129.86.154 -> 10.12.11.105 13:17:24.440 setsockopt MRT_ADD_VIF on vif 2: Operation not supported freebsd1# On Thu, Jan 28, 2010 at 12:53 PM, Nazeem =D9=86=D8=AC=D9=85 =D9=84=D8=AF=D9= =8A=D9=86 wrote: > > I have build the kernel with MROUTING option. Cause without it mrouted do= es > not execute. But is this a problem with the tunnel creation as it says > setsockopt MRT_ADD_VIF operation not permitted. > > The machine I use has 2 NICs. I have also enabled gateway "YES". > > I am trying to setup a multicast tunnel using mrouted. Anything I am > missing or gone wrong? Is a tunnel to be setup in some other way first? > > -Nazeem > > > On Thu, Jan 28, 2010 at 11:37 AM, Bruce Simpson wrot= e: > >> Did you remember to kldload ip_mroute or build your kernel with 'options >> MROUTING' ? >> > > > From owner-freebsd-net@FreeBSD.ORG Thu Jan 28 09:49:49 2010 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 CD6AF1065676 for ; Thu, 28 Jan 2010 09:49:49 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id 978F78FC14 for ; Thu, 28 Jan 2010 09:49:49 +0000 (UTC) Received: from compute1.internal (compute1.internal [10.202.2.41]) by gateway1.messagingengine.com (Postfix) with ESMTP id EEF27CD956; Thu, 28 Jan 2010 04:49:48 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Thu, 28 Jan 2010 04:49:48 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=message-id:date:from:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; s=smtpout; bh=viil8rwlEF6Y5Z4TIdtnMbnsvjQ=; b=QeBN5ylsI/jS7OrMWmxSQ1jg7l8mdpQWzNOMbFE4MLWEDl0s1mmQx4PzaabOlR5N6C1UCQHLCIfSxL9Yi+lb3ASdIVRYSBRb4KGk3dfBwuQgC/BM0MhJZGCD9vTVOOjuDKff9tBCttA8wAmQuI6gWJu9nmQZn+NWQtsTMiHnAUU= X-Sasl-enc: DOfHwC96d0Wl1ioV9KXtVGeUddrsBnaUelgMCeA5Yat/ 1264672188 Received: from anglepoise.lon.incunabulum.net (cpc2-dals7-0-0-cust253.hari.cable.virginmedia.com [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 7740D31BC5; Thu, 28 Jan 2010 04:49:48 -0500 (EST) Message-ID: <4B615DBA.6070007@incunabulum.net> Date: Thu, 28 Jan 2010 09:49:46 +0000 From: Bruce Simpson User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.7) Gecko/20100124 Thunderbird/3.0.1 MIME-Version: 1.0 To: =?UTF-8?B?TmF6ZWVtINmG2KzZhSDZhNiv2YrZhg==?= References: <7609d8391001270601m489ab6e6xe956d1539f2cbe4e@mail.gmail.com> <4B612997.8030505@incunabulum.net> <7609d8391001272323qa8694c0q9c716fc2e577eb47@mail.gmail.com> <7609d8391001272348m624201aco31f9a9ff2b3eb4e6@mail.gmail.com> In-Reply-To: <7609d8391001272348m624201aco31f9a9ff2b3eb4e6@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: MROUTED: Problem with vif installation 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, 28 Jan 2010 09:49:49 -0000 Tunnel support for MROUTING was removed several FreeBSD releases ago. We followed OpenBSD with this change because DVMRP's older, naive IP-in-IP encapsulation mechanism doesn't offer any benefit, and can't be administered. Also, PIM doesn't use it, and PIM is now the industry standard. thanks, BMS From owner-freebsd-net@FreeBSD.ORG Thu Jan 28 10:58:49 2010 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 BCA8E106566C for ; Thu, 28 Jan 2010 10:58:49 +0000 (UTC) (envelope-from nazeemnss@gmail.com) Received: from mail-px0-f183.google.com (mail-px0-f183.google.com [209.85.216.183]) by mx1.freebsd.org (Postfix) with ESMTP id 8DDB98FC08 for ; Thu, 28 Jan 2010 10:58:49 +0000 (UTC) Received: by pxi13 with SMTP id 13so413275pxi.3 for ; Thu, 28 Jan 2010 02:58:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=yZJN1loRCxtm4NP2IxtuEDP7I6PHc24nCFJ7R6CWK7c=; b=gzydnhHnBag+wc9XZAOjAsROlTgzgQ+I15p6L2CE2pNWNAT7WajIy+y/pQMSomIrUu lc1jT+kVLXt+yaderqHHpnSv38ePQpHNIrWn1hHxvZlZAWNQVhPPLEthL5op4oA31WlC BVorepWnml5ihD5Ezul0aZUv0l1shf7XdlH0s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=QefgnVAYVEzIvjdQMi9g+r7jZPI6XT+NqS3D+Mrw5NIunOtWZQevN4cMyrpjWghFNe KyUbif4ztoS0isasQ5+iVwXIeMLVPf+CrhqxN/3bIMqhjHXm1mhuAdplmAMhlc3+X1he lDKqM7M26eh2dRZfjd8kzEetAkSrasBcprWHU= MIME-Version: 1.0 Received: by 10.142.119.10 with SMTP id r10mr1735915wfc.43.1264676328663; Thu, 28 Jan 2010 02:58:48 -0800 (PST) In-Reply-To: <4B615DBA.6070007@incunabulum.net> References: <7609d8391001270601m489ab6e6xe956d1539f2cbe4e@mail.gmail.com> <4B612997.8030505@incunabulum.net> <7609d8391001272323qa8694c0q9c716fc2e577eb47@mail.gmail.com> <7609d8391001272348m624201aco31f9a9ff2b3eb4e6@mail.gmail.com> <4B615DBA.6070007@incunabulum.net> Date: Thu, 28 Jan 2010 16:28:48 +0530 Message-ID: <7609d8391001280258k707389c2m1da4c36bb13df150@mail.gmail.com> From: =?UTF-8?B?TmF6ZWVtINmG2KzZhSDZhNiv2YrZhg==?= To: Bruce Simpson Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: MROUTED: Problem with vif installation 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, 28 Jan 2010 10:58:49 -0000 Ok. Thanks. But I need to get tunnel working. Can you suggest some other way of getting a multicast tunnel work. The assumption is that there is a unicast cloud in between two mbone networks. So we need to forward the multicast traffic over the unicast tunnel. Application is for video transmission. thanks, Nazeem On Thu, Jan 28, 2010 at 3:19 PM, Bruce Simpson wrote: > Tunnel support for MROUTING was removed several FreeBSD releases ago. > > We followed OpenBSD with this change because DVMRP's older, naive IP-in-IP > encapsulation mechanism doesn't offer any benefit, and can't be > administered. Also, PIM doesn't use it, and PIM is now the industry > standard. > > thanks, > BMS > From owner-freebsd-net@FreeBSD.ORG Thu Jan 28 11:22:06 2010 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 F283B1065697; Thu, 28 Jan 2010 11:22:04 +0000 (UTC) (envelope-from prvs=1644450bb7=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 2AA058FC16; Thu, 28 Jan 2010 11:22:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=multiplay.co.uk; s=Multiplay; t=1264677108; x=1265281908; q=dns/txt; h=Received: Message-ID:From:To:Cc:References:Subject:Date:MIME-Version: Content-Type; bh=VdPoKULKysHVYTimwiD++5EogGUr4VbBCrvECIdKshg=; b=iskA8AOLNeMAy29Ggos2vvZ/o4qiZO4r6FM1UOc0McZ9INzw/sigUrFJ99RsWF exgFBi5As/WEUai8IXV7E8q05O3FADf0NlkmR3ygJyySuNdRhMvV6fE8Z0k2kCVc xnsl7pgor7a+YF3Hyjk3tqAZmG6TvUNJnm3v6cOIsS1Mg= X-MDAV-Processed: mail1.multiplay.co.uk, Thu, 28 Jan 2010 11:11:48 +0000 Received: from r2d2 by mail1.multiplay.co.uk (MDaemon PRO v10.0.4) with ESMTP id md50009325707.msg; Thu, 28 Jan 2010 11:11:47 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Thu, 28 Jan 2010 11:11:47 +0000 (not processed: message from trusted or authenticated source) X-Authenticated-Sender: Killing@multiplay.co.uk X-MDRemoteIP: 213.123.247.160 X-Return-Path: prvs=1644450bb7=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: From: "Steven Hartland" To: References: <8E2B6E11A79B4958B94B44A41C7D4298@multiplay.co.uk><61b573981001270543k6514a5g8d4f679777b69b49@mail.gmail.com><251ACDBA39F244B7B8D1520DE3C95DF1@multiplay.co.uk><61b573981001270752q4e21a8a9ldf19718ca3fb474c@mail.gmail.com> <3B80DBAE9B734A4187B8A0DF8FFA1706@multiplay.co.uk> Date: Thu, 28 Jan 2010 11:11:39 -0000 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0045_01CAA00A.A9FB0D40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: freebsd-net@freebsd.org Subject: Re: Problems getting lagg to balance using lacp 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, 28 Jan 2010 11:22:06 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0045_01CAA00A.A9FB0D40 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=response Content-Transfer-Encoding: 7bit I tried enabling lacp debugging and from what I can tell from the attached log file the issue is the fact lagg is creating two aggregators so instead of one lagg interface with one aggregator containing two ports I actually have two aggregators hence its picking one of them to send the data from. Important items:- Jan 28 10:17:24 test1 kernel: em1: aggregator created Jan 28 10:25:11 test1 kernel: em0: aggregator created ... Jan 28 10:17:27 test1 kernel: [(8000,00-30-48-33-EC-44,0090,0000,0000),(8000,00-0A-8B-9B-CC-00,0002,0000,0000)], speed=1000000000, nports=1 I would expect to be seeing: "compatible aggregator found" instead of the second "aggregator created" The only problem with this analysis is that with debugging enable the Cisco got really upset and disabled both ports, not sure why debugging should cause this but it may well have thrown out the information. What do people think? Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. ------=_NextPart_000_0045_01CAA00A.A9FB0D40 Content-Type: text/plain; format=flowed; name="lagg-issue.log"; reply-type=response Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="lagg-issue.log" Jan 28 10:17:19 test1 kernel: em0: media changed 0x0 -> 0x20, ether =3D = 1, fdx =3D 0, link =3D 0=0A= Jan 28 10:17:19 test1 kernel: em0: partner timeout changed=0A= Jan 28 10:17:19 test1 kernel: em0: -> UNSELECTED=0A= Jan 28 10:17:19 test1 kernel: em1: media changed 0x0 -> 0x20, ether =3D = 1, fdx =3D 0, link =3D 0=0A= Jan 28 10:17:19 test1 kernel: em1: partner timeout changed=0A= Jan 28 10:17:19 test1 kernel: em1: -> UNSELECTED=0A= Jan 28 10:17:19 test1 kernel: lacp_select_tx_port: no active aggregator=0A= Jan 28 10:17:22 test1 kernel: em0: media changed 0x20 -> 0x100030, ether = =3D 1, fdx =3D 1, link =3D 1=0A= Jan 28 10:17:22 test1 kernel: em0: -> UNSELECTED=0A= Jan 28 10:17:22 test1 kernel: em0: link state changed to UP=0A= Jan 28 10:17:22 test1 kernel: lagg0: link state changed to UP=0A= Jan 28 10:17:22 test1 kernel: em1: media changed 0x20 -> 0x100030, ether = =3D 1, fdx =3D 1, link =3D 1=0A= Jan 28 10:17:22 test1 kernel: em1: -> UNSELECTED=0A= Jan 28 10:17:22 test1 kernel: em1: link state changed to UP=0A= Jan 28 10:17:22 test1 kernel: em1: port = lagid=3D[(8000,00-30-48-33-EC-44,0090,8000,0002),(FFFF,00-00-00-00-00-00,= 0000,FFFF,0000)]=0A= Jan 28 10:17:22 test1 kernel: em1: aggregator created=0A= Jan 28 10:17:22 test1 kernel: em1: aggregator = lagid=3D[(8000,00-30-48-33-EC-44,0090,0000,0000),(FFFF,00-00-00-00-00-00,= 0000,0000,0000)]=0A= Jan 28 10:17:22 test1 kernel: em1: mux_state 0 -> 1=0A= Jan 28 10:17:22 test1 kernel: em0: port = lagid=3D[(8000,00-30-48-33-EC-44,0090,8000,0001),(FFFF,00-00-00-00-00-00,= 0000,FFFF,0000)]=0A= Jan 28 10:17:22 test1 kernel: em0: aggregator created=0A= Jan 28 10:17:22 test1 kernel: em0: aggregator = lagid=3D[(8000,00-30-48-33-EC-44,0090,0000,0000),(FFFF,00-00-00-00-00-00,= 0000,0000,0000)]=0A= Jan 28 10:17:22 test1 kernel: em0: mux_state 0 -> 1=0A= Jan 28 10:17:22 test1 kernel: em0: lacpdu receive=0A= Jan 28 10:17:22 test1 kernel: = actor=3D(8000,00-0A-8B-9B-CC-00,0002,8000,0323)=0A= Jan 28 10:17:22 test1 kernel: = actor.state=3Dc7=0A= Jan 28 10:17:22 test1 kernel: = partner=3D(0000,00-00-00-00-00-00,0000,0000,0000)=0A= Jan 28 10:17:22 test1 kernel: partner.state=3D2=0A= Jan 28 10:17:22 test1 kernel: maxdelay=3D32768=0A= Jan 28 10:17:22 test1 kernel: em0: lacp_sm_rx_update_ntt: assert ntt=0A= Jan 28 10:17:22 test1 kernel: em0: old pstate = 38=0A= Jan 28 10:17:22 test1 kernel: em0: new pstate = c7=0A= Jan 28 10:17:22 test1 kernel: em0: partner timeout changed=0A= Jan 28 10:17:22 test1 kernel: em0: lacpdu transmit=0A= Jan 28 10:17:22 test1 kernel: = actor=3D(8000,00-30-48-33-EC-44,0090,8000,0001)=0A= Jan 28 10:17:22 test1 kernel: actor.state=3D5=0A= Jan 28 10:17:22 test1 kernel: = partner=3D(8000,00-0A-8B-9B-CC-00,0002,8000,0323)=0A= Jan 28 10:17:22 test1 kernel: = partner.state=3Dc7=0A= Jan 28 10:17:22 test1 kernel: maxdelay=3D0=0A= Jan 28 10:17:23 test1 kernel: em1: lacpdu receive=0A= Jan 28 10:17:23 test1 kernel: = actor=3D(8000,00-0A-8B-9B-CC-00,0002,8000,032B)=0A= Jan 28 10:17:23 test1 kernel: = actor.state=3Dc7=0A= Jan 28 10:17:23 test1 kernel: = partner=3D(0000,00-00-00-00-00-00,0000,0000,0000)=0A= Jan 28 10:17:23 test1 kernel: partner.state=3D2=0A= Jan 28 10:17:23 test1 kernel: maxdelay=3D32768=0A= Jan 28 10:17:23 test1 kernel: em1: lacp_sm_rx_update_ntt: assert ntt=0A= Jan 28 10:17:23 test1 kernel: em1: old pstate = 38=0A= Jan 28 10:17:23 test1 kernel: em1: new pstate = c7=0A= Jan 28 10:17:23 test1 kernel: em1: partner timeout changed=0A= Jan 28 10:17:23 test1 kernel: em1: lacpdu transmit=0A= Jan 28 10:17:23 test1 kernel: = actor=3D(8000,00-30-48-33-EC-44,0090,8000,0002)=0A= Jan 28 10:17:23 test1 kernel: actor.state=3D5=0A= Jan 28 10:17:23 test1 kernel: = partner=3D(8000,00-0A-8B-9B-CC-00,0002,8000,032B)=0A= Jan 28 10:17:23 test1 kernel: = partner.state=3Dc7=0A= Jan 28 10:17:23 test1 kernel: maxdelay=3D0=0A= Jan 28 10:17:23 test1 kernel: em1: collecting disabled=0A= Jan 28 10:17:23 test1 kernel: lacp_aggregator_delref: = lagid=3D[(8000,00-30-48-33-EC-44,0090,0000,0000),(FFFF,00-00-00-00-00-00,= 0000,0000,0000)], refcnt 1 -> 0=0A= Jan 28 10:17:23 test1 kernel: em1: mux_state 1 -> 0=0A= Jan 28 10:17:23 test1 kernel: em1: lacpdu transmit=0A= Jan 28 10:17:23 test1 kernel: = actor=3D(8000,00-30-48-33-EC-44,0090,8000,0002)=0A= Jan 28 10:17:23 test1 kernel: actor.state=3D5=0A= Jan 28 10:17:23 test1 kernel: = partner=3D(8000,00-0A-8B-9B-CC-00,0002,8000,032B)=0A= Jan 28 10:17:23 test1 kernel: = partner.state=3Dc7=0A= Jan 28 10:17:23 test1 kernel: maxdelay=3D0=0A= Jan 28 10:17:23 test1 kernel: em0: collecting disabled=0A= Jan 28 10:17:23 test1 kernel: lacp_aggregator_delref: = lagid=3D[(8000,00-30-48-33-EC-44,0090,0000,0000),(FFFF,00-00-00-00-00-00,= 0000,0000,0000)], refcnt 1 -> 0=0A= Jan 28 10:17:23 test1 kernel: em0: mux_state 1 -> 0=0A= Jan 28 10:17:23 test1 kernel: em0: lacpdu transmit=0A= Jan 28 10:17:23 test1 kernel: = actor=3D(8000,00-30-48-33-EC-44,0090,8000,0001)=0A= Jan 28 10:17:23 test1 kernel: actor.state=3D5=0A= Jan 28 10:17:23 test1 kernel: = partner=3D(8000,00-0A-8B-9B-CC-00,0002,8000,0323)=0A= Jan 28 10:17:23 test1 kernel: = partner.state=3Dc7=0A= Jan 28 10:17:23 test1 kernel: maxdelay=3D0=0A= Jan 28 10:17:24 test1 kernel: em0: lacpdu receive=0A= Jan 28 10:17:24 test1 kernel: = actor=3D(8000,00-0A-8B-9B-CC-00,0002,8000,0323)=0A= Jan 28 10:17:24 test1 kernel: = actor.state=3Df=0A= Jan 28 10:17:24 test1 kernel: = partner=3D(8000,00-30-48-33-EC-44,0090,8000,0001)=0A= Jan 28 10:17:24 test1 kernel: partner.state=3D5=0A= Jan 28 10:17:24 test1 kernel: maxdelay=3D32768=0A= Jan 28 10:17:24 test1 kernel: em0: old pstate = c7=0A= Jan 28 10:17:24 test1 kernel: em0: new pstate = f=0A= Jan 28 10:17:24 test1 kernel: em1: port = lagid=3D[(8000,00-30-48-33-EC-44,0090,8000,0002),(8000,00-0A-8B-9B-CC-00,= 0002,8000,032B)]=0A= Jan 28 10:17:24 test1 kernel: em1: aggregator created=0A= Jan 28 10:17:24 test1 kernel: em1: aggregator = lagid=3D[(8000,00-30-48-33-EC-44,0090,0000,0000),(8000,00-0A-8B-9B-CC-00,= 0002,0000,0000)]=0A= Jan 28 10:17:24 test1 kernel: em1: mux_state 0 -> 1=0A= Jan 28 10:17:24 test1 kernel: em1: lacpdu transmit=0A= Jan 28 10:17:24 test1 kernel: = actor=3D(8000,00-30-48-33-EC-44,0090,8000,0002)=0A= Jan 28 10:17:24 test1 kernel: actor.state=3D5=0A= Jan 28 10:17:24 test1 kernel: = partner=3D(8000,00-0A-8B-9B-CC-00,0002,8000,032B)=0A= Jan 28 10:17:24 test1 kernel: = partner.state=3Dc7=0A= Jan 28 10:17:24 test1 kernel: maxdelay=3D0=0A= Jan 28 10:17:24 test1 kernel: em0: port = lagid=3D[(8000,00-30-48-33-EC-44,0090,8000,0001),(8000,00-0A-8B-9B-CC-00,= 0002,8000,0323)]=0A= Jan 28 10:17:24 test1 kernel: em0: compatible aggregator found=0A= Jan 28 10:17:24 test1 kernel: lacp_aggregator_addref: = lagid=3D[(8000,00-30-48-33-EC-44,0090,0000,0000),(8000,00-0A-8B-9B-CC-00,= 0002,0000,0000)], refcnt 1 -> 2=0A= Jan 28 10:17:24 test1 kernel: em0: aggregator = lagid=3D[(8000,00-30-48-33-EC-44,0090,0000,0000),(8000,00-0A-8B-9B-CC-00,= 0002,0000,0000)]=0A= Jan 28 10:17:24 test1 kernel: em0: mux_state 0 -> 1=0A= Jan 28 10:17:24 test1 kernel: em0: lacpdu transmit=0A= Jan 28 10:17:24 test1 kernel: = actor=3D(8000,00-30-48-33-EC-44,0090,8000,0001)=0A= Jan 28 10:17:24 test1 kernel: actor.state=3D5=0A= Jan 28 10:17:24 test1 kernel: = partner=3D(8000,00-0A-8B-9B-CC-00,0002,8000,0323)=0A= Jan 28 10:17:24 test1 kernel: = partner.state=3Df=0A= Jan 28 10:17:24 test1 kernel: maxdelay=3D0=0A= Jan 28 10:17:25 test1 kernel: em1: lacpdu receive=0A= Jan 28 10:17:25 test1 kernel: = actor=3D(8000,00-0A-8B-9B-CC-00,0002,8000,032B)=0A= Jan 28 10:17:25 test1 kernel: = actor.state=3Df=0A= Jan 28 10:17:25 test1 kernel: = partner=3D(8000,00-30-48-33-EC-44,0090,8000,0002)=0A= Jan 28 10:17:25 test1 kernel: partner.state=3D5=0A= Jan 28 10:17:25 test1 kernel: maxdelay=3D32768=0A= Jan 28 10:17:25 test1 kernel: em1: old pstate = c7=0A= Jan 28 10:17:25 test1 kernel: em1: new pstate = f=0A= Jan 28 10:17:25 test1 kernel: em1: lacpdu transmit=0A= Jan 28 10:17:25 test1 kernel: = actor=3D(8000,00-30-48-33-EC-44,0090,8000,0002)=0A= Jan 28 10:17:25 test1 kernel: actor.state=3D5=0A= Jan 28 10:17:25 test1 kernel: = partner=3D(8000,00-0A-8B-9B-CC-00,0002,8000,032B)=0A= Jan 28 10:17:25 test1 kernel: = partner.state=3Df=0A= Jan 28 10:17:25 test1 kernel: maxdelay=3D0=0A= Jan 28 10:17:25 test1 kernel: em0: lacpdu transmit=0A= Jan 28 10:17:25 test1 kernel: = actor=3D(8000,00-30-48-33-EC-44,0090,8000,0001)=0A= Jan 28 10:17:25 test1 kernel: actor.state=3D5=0A= Jan 28 10:17:25 test1 kernel: = partner=3D(8000,00-0A-8B-9B-CC-00,0002,8000,0323)=0A= Jan 28 10:17:25 test1 kernel: = partner.state=3Df=0A= Jan 28 10:17:25 test1 kernel: maxdelay=3D0=0A= Jan 28 10:17:26 test1 kernel: em1: lacp_sm_mux_timer: aggregator = [(8000,00-30-48-33-EC-44,0090,0000,0000),(8000,00-0A-8B-9B-CC-00,0002,000= 0,0000)], pending 2 -> 1=0A= Jan 28 10:17:26 test1 kernel: em1: lacpdu transmit=0A= Jan 28 10:17:26 test1 kernel: = actor=3D(8000,00-30-48-33-EC-44,0090,8000,0002)=0A= Jan 28 10:17:26 test1 kernel: actor.state=3D5=0A= Jan 28 10:17:26 test1 kernel: = partner=3D(8000,00-0A-8B-9B-CC-00,0002,8000,032B)=0A= Jan 28 10:17:26 test1 kernel: = partner.state=3Df=0A= Jan 28 10:17:26 test1 kernel: maxdelay=3D0=0A= Jan 28 10:17:26 test1 kernel: em0: lacp_sm_mux_timer: aggregator = [(8000,00-30-48-33-EC-44,0090,0000,0000),(8000,00-0A-8B-9B-CC-00,0002,000= 0,0000)], pending 1 -> 0=0A= Jan 28 10:17:26 test1 kernel: em0: collecting disabled=0A= Jan 28 10:17:26 test1 kernel: em0: mux_state 1 -> 2=0A= Jan 28 10:17:26 test1 kernel: em0: collecting enabled=0A= Jan 28 10:17:26 test1 kernel: em0: mux_state 2 -> 3=0A= Jan 28 10:17:26 test1 kernel: em0: lacpdu transmit=0A= Jan 28 10:17:26 test1 kernel: = actor=3D(8000,00-30-48-33-EC-44,0090,8000,0001)=0A= Jan 28 10:17:26 test1 kernel: = actor.state=3D1d=0A= Jan 28 10:17:26 test1 kernel: = partner=3D(8000,00-0A-8B-9B-CC-00,0002,8000,0323)=0A= Jan 28 10:17:26 test1 kernel: = partner.state=3Df=0A= Jan 28 10:17:26 test1 kernel: maxdelay=3D0=0A= Jan 28 10:17:26 test1 kernel: em0: lacpdu receive=0A= Jan 28 10:17:26 test1 kernel: = actor=3D(8000,00-0A-8B-9B-CC-00,0002,8000,0323)=0A= Jan 28 10:17:26 test1 kernel: = actor.state=3D3d=0A= Jan 28 10:17:26 test1 kernel: = partner=3D(8000,00-30-48-33-EC-44,0090,8000,0001)=0A= Jan 28 10:17:26 test1 kernel: = partner.state=3D1d=0A= Jan 28 10:17:26 test1 kernel: maxdelay=3D32768=0A= Jan 28 10:17:26 test1 kernel: em0: old pstate = f=0A= Jan 28 10:17:26 test1 kernel: em0: new pstate = 3d=0A= Jan 28 10:17:26 test1 kernel: em0: partner timeout changed=0A= Jan 28 10:17:27 test1 kernel: em1: collecting disabled=0A= Jan 28 10:17:27 test1 kernel: em1: mux_state 1 -> 2=0A= Jan 28 10:17:27 test1 kernel: em1: collecting enabled=0A= Jan 28 10:17:27 test1 kernel: em1: mux_state 2 -> 3=0A= Jan 28 10:17:27 test1 kernel: em1: lacpdu transmit=0A= Jan 28 10:17:27 test1 kernel: = actor=3D(8000,00-30-48-33-EC-44,0090,8000,0002)=0A= Jan 28 10:17:27 test1 kernel: = actor.state=3D1d=0A= Jan 28 10:17:27 test1 kernel: = partner=3D(8000,00-0A-8B-9B-CC-00,0002,8000,032B)=0A= Jan 28 10:17:27 test1 kernel: = partner.state=3Df=0A= Jan 28 10:17:27 test1 kernel: maxdelay=3D0=0A= Jan 28 10:17:27 test1 kernel: em0: enable distributing on aggregator = [(8000,00-30-48-33-EC-44,0090,0000,0000),(8000,00-0A-8B-9B-CC-00,0002,000= 0,0000)], nports 0 -> 1=0A= Jan 28 10:17:27 test1 kernel: lacp_select_active_aggregator:=0A= Jan 28 10:17:27 test1 kernel: = [(8000,00-30-48-33-EC-44,0090,0000,0000),(8000,00-0A-8B-9B-CC-00,0002,000= 0,0000)], speed=3D1000000000, nports=3D1=0A= Jan 28 10:17:27 test1 kernel: active aggregator changed=0A= Jan 28 10:17:27 test1 kernel: old (none)=0A= Jan 28 10:17:27 test1 kernel: new = [(8000,00-30-48-33-EC-44,0090,0000,0000),(8000,00-0A-8B-9B-CC-00,0002,000= 0,0000)]=0A= Jan 28 10:17:27 test1 kernel: Set table 1 with 1 ports=0A= Jan 28 10:17:27 test1 kernel: lacp_suppress_distributing=0A= Jan 28 10:17:27 test1 kernel: em1: marker transmit, port=3D2, = sys=3D00:30:48:33:ec:44, id=3D1=0A= Jan 28 10:17:27 test1 kernel: em0: marker transmit, port=3D1, = sys=3D00:30:48:33:ec:44, id=3D1=0A= Jan 28 10:17:27 test1 kernel: em0: mux_state 3 -> 4=0A= Jan 28 10:17:27 test1 kernel: em1: lacpdu receive=0A= Jan 28 10:17:27 test1 kernel: = actor=3D(8000,00-0A-8B-9B-CC-00,0002,8000,032B)=0A= Jan 28 10:17:27 test1 kernel: = actor.state=3D3d=0A= Jan 28 10:17:27 test1 kernel: = partner=3D(8000,00-30-48-33-EC-44,0090,8000,0002)=0A= Jan 28 10:17:27 test1 kernel: = partner.state=3D1d=0A= Jan 28 10:17:27 test1 kernel: maxdelay=3D32768=0A= Jan 28 10:17:27 test1 kernel: em1: old pstate = f=0A= Jan 28 10:17:27 test1 kernel: em1: new pstate = 3dem0: =0A= Jan 28 10:17:27 test1 kernel: em1: marker response, port=3D1, = sys=3D00:30:48:33:ec:44, id=3D1partner timeout changed=0A= Jan 28 10:17:27 test1 kernel: =0A= Jan 28 10:17:28 test1 kernel: em1: enable distributing on aggregator = [(8000,00-30-48-33-EC-44,0090,0000,0000),(8000,00-0A-8B-9B-CC-00,0002,000= 0,0000)], nports 1 -> 2=0A= Jan 28 10:17:28 test1 kernel: lacp_suppress_distributing=0A= Jan 28 10:17:28 test1 kernel: em1: marker transmit, port=3D2, = sys=3D00:30:48:33:ec:44, id=3D2=0A= Jan 28 10:17:28 test1 kernel: em0: marker transmit, port=3D1, = sys=3D00:30:48:33:ec:44, id=3D2em1: =0A= Jan 28 10:17:28 test1 kernel: Set table 0 with 2 portsmarker response, = port=3D2, sys=3D00:30:48:33:ec:44, id=3D2em0: =0A= Jan 28 10:17:28 test1 kernel: em1: marker response, port=3D1, = sys=3D00:30:48:33:ec:44, id=3D2=0A= Jan 28 10:17:28 test1 kernel: =0A= Jan 28 10:17:28 test1 kernel: mux_state 3 -> 4=0A= Jan 28 10:17:28 test1 kernel: queue flush complete=0A= Jan 28 10:17:29 test1 kernel: em0: lacpdu receive=0A= Jan 28 10:17:29 test1 kernel: = actor=3D(8000,00-0A-8B-9B-CC-00,0002,8000,0323)=0A= Jan 28 10:17:29 test1 kernel: = actor.state=3Dbd=0A= Jan 28 10:17:29 test1 kernel: = partner=3D(8000,00-30-48-33-EC-44,0090,8000,0001)=0A= Jan 28 10:17:29 test1 kernel: = partner.state=3D17=0A= Jan 28 10:17:29 test1 kernel: maxdelay=3D32768=0A= Jan 28 10:17:29 test1 kernel: em0: lacp_sm_rx_update_ntt: assert ntt=0A= Jan 28 10:17:29 test1 kernel: em0: old pstate = 3d=0A= Jan 28 10:17:29 test1 kernel: em0: new pstate = bd=0A= Jan 28 10:17:29 test1 kernel: em0: lacpdu transmit=0A= Jan 28 10:17:29 test1 kernel: = actor=3D(8000,00-30-48-33-EC-44,0090,8000,0001)=0A= Jan 28 10:17:29 test1 kernel: = actor.state=3D3d=0A= Jan 28 10:17:29 test1 kernel: = partner=3D(8000,00-0A-8B-9B-CC-00,0002,8000,0323)=0A= Jan 28 10:17:29 test1 kernel: = partner.state=3Dbd=0A= Jan 28 10:17:29 test1 kernel: maxdelay=3D0=0A= Jan 28 10:17:29 test1 kernel: em0: lacpdu receive=0A= Jan 28 10:17:29 test1 kernel: = actor=3D(8000,00-0A-8B-9B-CC-00,0002,8000,0323)=0A= Jan 28 10:17:29 test1 kernel: = actor.state=3D8f=0A= Jan 28 10:17:29 test1 kernel: = partner=3D(8000,00-30-48-33-EC-44,0090,8000,0001)=0A= Jan 28 10:17:29 test1 kernel: = partner.state=3D17=0A= Jan 28 10:17:29 test1 kernel: maxdelay=3D32768=0A= Jan 28 10:17:29 test1 kernel: em0: lacp_sm_rx_update_ntt: assert ntt=0A= Jan 28 10:17:29 test1 kernel: em0: old pstate = bd=0A= Jan 28 10:17:29 test1 kernel: em0: new pstate = 8f=0A= Jan 28 10:17:29 test1 kernel: em0: partner timeout changed=0A= Jan 28 10:17:29 test1 kernel: em0: lacpdu transmit=0A= Jan 28 10:17:29 test1 kernel: = actor=3D(8000,00-30-48-33-EC-44,0090,8000,0001)=0A= Jan 28 10:17:29 test1 kernel: = actor.state=3D3d=0A= Jan 28 10:17:29 test1 kernel: = partner=3D(8000,00-0A-8B-9B-CC-00,0002,8000,0323)=0A= Jan 28 10:17:29 test1 kernel: = partner.state=3D8f=0A= Jan 28 10:17:29 test1 kernel: maxdelay=3D0=0A= Jan 28 10:17:29 test1 kernel: em0: lacpdu receive=0A= Jan 28 10:17:29 test1 kernel: = actor=3D(8000,00-0A-8B-9B-CC-00,0002,8000,0323)=0A= Jan 28 10:17:29 test1 kernel: = actor.state=3D3d=0A= Jan 28 10:17:29 test1 kernel: = partner=3D(8000,00-30-48-33-EC-44,0090,8000,0001)=0A= Jan 28 10:17:29 test1 kernel: = partner.state=3D3d=0A= Jan 28 10:17:29 test1 kernel: maxdelay=3D32768=0A= Jan 28 10:17:29 test1 kernel: em0: old pstate = 8f=0A= Jan 28 10:17:29 test1 kernel: em0: new pstate = 3d=0A= Jan 28 10:17:29 test1 kernel: em0: partner timeout changed=0A= Jan 28 10:17:30 test1 kernel: em1: lacpdu receive=0A= Jan 28 10:17:30 test1 kernel: = actor=3D(8000,00-0A-8B-9B-CC-00,0002,8000,032B)=0A= Jan 28 10:17:30 test1 kernel: = actor.state=3Dbd=0A= Jan 28 10:17:30 test1 kernel: = partner=3D(8000,00-30-48-33-EC-44,0090,8000,0002)=0A= Jan 28 10:17:30 test1 kernel: = partner.state=3D17=0A= Jan 28 10:17:30 test1 kernel: maxdelay=3D32768=0A= Jan 28 10:17:30 test1 kernel: em1: lacp_sm_rx_update_ntt: assert ntt=0A= Jan 28 10:17:30 test1 kernel: em1: old pstate = 3d=0A= Jan 28 10:17:30 test1 kernel: em1: new pstate = bd=0A= Jan 28 10:17:30 test1 kernel: em1: lacpdu transmit=0A= Jan 28 10:17:30 test1 kernel: = actor=3D(8000,00-30-48-33-EC-44,0090,8000,0002)=0A= Jan 28 10:17:30 test1 kernel: = actor.state=3D3d=0A= Jan 28 10:17:30 test1 kernel: = partner=3D(8000,00-0A-8B-9B-CC-00,0002,8000,032B)=0A= Jan 28 10:17:30 test1 kernel: = partner.state=3Dbd=0A= Jan 28 10:17:30 test1 kernel: maxdelay=3D0=0A= Jan 28 10:17:30 test1 kernel: em1: lacpdu receive=0A= Jan 28 10:17:30 test1 kernel: = actor=3D(8000,00-0A-8B-9B-CC-00,0002,8000,032B)=0A= Jan 28 10:17:30 test1 kernel: = actor.state=3D8f=0A= Jan 28 10:17:30 test1 kernel: = partner=3D(8000,00-30-48-33-EC-44,0090,8000,0002)=0A= Jan 28 10:17:30 test1 kernel: = partner.state=3D17=0A= Jan 28 10:17:30 test1 kernel: maxdelay=3D32768=0A= Jan 28 10:17:30 test1 kernel: em1: lacp_sm_rx_update_ntt: assert ntt=0A= Jan 28 10:17:30 test1 kernel: em1: old pstate = bd=0A= Jan 28 10:17:30 test1 kernel: em1: new pstate = 8f=0A= Jan 28 10:17:30 test1 kernel: em1: partner timeout changed=0A= Jan 28 10:17:30 test1 kernel: em1: lacpdu transmit=0A= Jan 28 10:17:30 test1 kernel: = actor=3D(8000,00-30-48-33-EC-44,0090,8000,0002)=0A= Jan 28 10:17:30 test1 kernel: = actor.state=3D3d=0A= Jan 28 10:17:30 test1 kernel: = partner=3D(8000,00-0A-8B-9B-CC-00,0002,8000,032B)=0A= Jan 28 10:17:30 test1 kernel: = partner.state=3D8f=0A= Jan 28 10:17:30 test1 kernel: maxdelay=3D0=0A= Jan 28 10:17:30 test1 kernel: em1: lacpdu receive=0A= Jan 28 10:17:30 test1 kernel: = actor=3D(8000,00-0A-8B-9B-CC-00,0002,8000,032B)=0A= Jan 28 10:17:30 test1 kernel: = actor.state=3D3d=0A= Jan 28 10:17:30 test1 kernel: = partner=3D(8000,00-30-48-33-EC-44,0090,8000,0002)=0A= Jan 28 10:17:30 test1 kernel: = partner.state=3D3d=0A= Jan 28 10:17:30 test1 kernel: maxdelay=3D32768=0A= Jan 28 10:17:30 test1 kernel: em1: old pstate = 8f=0A= Jan 28 10:17:30 test1 kernel: em1: new pstate = 3d=0A= Jan 28 10:17:30 test1 kernel: em1: partner timeout changed=0A= Jan 28 10:17:31 test1 kernel: lacp_transit_expire=0A= Jan 28 10:17:32 test1 kernel: em0: lacpdu receive=0A= Jan 28 10:17:32 test1 kernel: = actor=3D(8000,00-0A-8B-9B-CC-00,0002,8000,0323)=0A= Jan 28 10:17:32 test1 kernel: = actor.state=3Dbd=0A= Jan 28 10:17:32 test1 kernel: = partner=3D(8000,00-30-48-33-EC-44,0090,8000,0001)=0A= Jan 28 10:17:32 test1 kernel: = partner.state=3D37=0A= Jan 28 10:17:32 test1 kernel: maxdelay=3D32768=0A= Jan 28 10:17:32 test1 kernel: em0: lacp_sm_rx_update_ntt: assert ntt=0A= Jan 28 10:17:32 test1 kernel: em0: old pstate = 3d=0A= Jan 28 10:17:32 test1 kernel: em0: new pstate = bd=0A= Jan 28 10:17:32 test1 kernel: em0: lacpdu transmit=0A= Jan 28 10:17:32 test1 kernel: = actor=3D(8000,00-30-48-33-EC-44,0090,8000,0001)=0A= Jan 28 10:17:32 test1 kernel: = actor.state=3D3d=0A= Jan 28 10:17:32 test1 kernel: = partner=3D(8000,00-0A-8B-9B-CC-00,0002,8000,0323)=0A= Jan 28 10:17:32 test1 kernel: = partner.state=3Dbd=0A= Jan 28 10:17:32 test1 kernel: maxdelay=3D0=0A= Jan 28 10:17:32 test1 kernel: em0: lacpdu receive=0A= Jan 28 10:17:32 test1 kernel: = actor=3D(8000,00-0A-8B-9B-CC-00,0002,8000,0323)=0A= Jan 28 10:17:32 test1 kernel: = actor.state=3D8f=0A= Jan 28 10:17:32 test1 kernel: = partner=3D(8000,00-30-48-33-EC-44,0090,8000,0001)=0A= Jan 28 10:17:32 test1 kernel: = partner.state=3D37=0A= Jan 28 10:17:32 test1 kernel: maxdelay=3D32768=0A= Jan 28 10:17:32 test1 kernel: em0: lacp_sm_rx_update_ntt: assert ntt=0A= Jan 28 10:17:32 test1 kernel: em0: old pstate = bd=0A= Jan 28 10:17:32 test1 kernel: em0: new pstate = 8f=0A= Jan 28 10:17:32 test1 kernel: em0: partner timeout changed=0A= Jan 28 10:17:32 test1 kernel: em0: lacpdu transmit=0A= Jan 28 10:17:32 test1 kernel: = actor=3D(8000,00-30-48-33-EC-44,0090,8000,0001)=0A= Jan 28 10:17:32 test1 kernel: = actor.state=3D3d=0A= Jan 28 10:17:32 test1 kernel: = partner=3D(8000,00-0A-8B-9B-CC-00,0002,8000,0323)=0A= Jan 28 10:17:32 test1 kernel: = partner.state=3D8f=0A= Jan 28 10:17:32 test1 kernel: maxdelay=3D0=0A= Jan 28 10:17:32 test1 kernel: em0: lacpdu receive=0A= Jan 28 10:17:32 test1 kernel: = actor=3D(8000,00-0A-8B-9B-CC-00,0002,8000,0323)=0A= Jan 28 10:17:32 test1 kernel: = actor.state=3D3d=0A= Jan 28 10:17:32 test1 kernel: = partner=3D(8000,00-30-48-33-EC-44,0090,8000,0001)=0A= Jan 28 10:17:32 test1 kernel: = partner.state=3D3d=0A= Jan 28 10:17:32 test1 kernel: maxdelay=3D32768=0A= Jan 28 10:17:32 test1 kernel: em0: old pstate = 8f=0A= Jan 28 10:17:32 test1 kernel: em0: new pstate = 3d=0A= Jan 28 10:17:32 test1 kernel: em0: partner timeout changed=0A= Jan 28 10:17:33 test1 kernel: em1: lacpdu receive=0A= Jan 28 10:17:33 test1 kernel: = actor=3D(8000,00-0A-8B-9B-CC-00,0002,8000,032B)=0A= Jan 28 10:17:33 test1 kernel: = actor.state=3Dbd=0A= Jan 28 10:17:33 test1 kernel: = partner=3D(8000,00-30-48-33-EC-44,0090,8000,0002)=0A= Jan 28 10:17:33 test1 kernel: = partner.state=3D37=0A= Jan 28 10:17:33 test1 kernel: maxdelay=3D32768=0A= Jan 28 10:17:33 test1 kernel: em1: lacp_sm_rx_update_ntt: assert ntt=0A= Jan 28 10:17:33 test1 kernel: em1: old pstate = 3d=0A= Jan 28 10:17:33 test1 kernel: em1: new pstate = bd=0A= Jan 28 10:17:33 test1 kernel: em1: lacpdu transmit=0A= Jan 28 10:17:33 test1 kernel: = actor=3D(8000,00-30-48-33-EC-44,0090,8000,0002)=0A= Jan 28 10:17:33 test1 kernel: = actor.state=3D3d=0A= Jan 28 10:17:33 test1 kernel: = partner=3D(8000,00-0A-8B-9B-CC-00,0002,8000,032B)=0A= Jan 28 10:17:33 test1 kernel: = partner.state=3Dbd=0A= Jan 28 10:17:33 test1 kernel: maxdelay=3D0=0A= Jan 28 10:17:33 test1 kernel: em1: lacpdu receive=0A= Jan 28 10:17:33 test1 kernel: = actor=3D(8000,00-0A-8B-9B-CC-00,0002,8000,032B)=0A= Jan 28 10:17:33 test1 kernel: = actor.state=3D8f=0A= Jan 28 10:17:33 test1 kernel: = partner=3D(8000,00-30-48-33-EC-44,0090,8000,0002)=0A= Jan 28 10:17:33 test1 kernel: = partner.state=3D37=0A= Jan 28 10:17:33 test1 kernel: maxdelay=3D32768=0A= Jan 28 10:17:33 test1 kernel: em1: =0A= Jan 28 10:17:33 test1 kernel: lacp_sm_rx_update_ntt: assert ntt=0A= Jan 28 10:17:33 test1 kernel: =0A= Jan 28 10:17:33 test1 kernel: em1: old pstate = bd=0A= Jan 28 10:17:33 test1 kernel: =0A= Jan 28 10:17:33 test1 kernel: em1: new pstate = 8f=0A= Jan 28 10:17:33 test1 kernel: em1: partner timeout changed=0A= Jan 28 10:17:33 test1 kernel: em1: lacpdu transmit=0A= Jan 28 10:17:33 test1 kernel: = actor=3D(8000,00-30-48-33-EC-44,0090,8000,0002)=0A= Jan 28 10:17:33 test1 kernel: = actor.state=3D3d=0A= Jan 28 10:17:33 test1 kernel: = partner=3D(8000,00-0A-8B-9B-CC-00,0002,8000,032B)=0A= Jan 28 10:17:33 test1 kernel: = partner.state=3D8f=0A= Jan 28 10:17:33 test1 kernel: maxdelay=3D0=0A= Jan 28 10:17:33 test1 kernel: em1: lacpdu receive=0A= Jan 28 10:17:33 test1 kernel: = actor=3D(8000,00-0A-8B-9B-CC-00,0002,8000,032B)=0A= Jan 28 10:17:33 test1 kernel: = actor.state=3D3d=0A= Jan 28 10:17:33 test1 kernel: = partner=3D(8000,00-30-48-33-EC-44,0090,8000,0002)=0A= Jan 28 10:17:33 test1 kernel: = partner.state=3D3d=0A= Jan 28 10:17:33 test1 kernel: maxdelay=3D32768=0A= Jan 28 10:17:33 test1 kernel: em1: old pstate = 8f=0A= Jan 28 10:17:33 test1 kernel: em1: new pstate = 3d=0A= Jan 28 10:17:33 test1 kernel: em1: partner timeout changed=0A= Jan 28 10:17:35 test1 kernel: em0: lacpdu receive=0A= Jan 28 10:17:35 test1 kernel: = actor=3D(8000,00-0A-8B-9B-CC-00,0002,8000,0323)=0A= Jan 28 10:17:35 test1 kernel: = actor.state=3Dbd=0A= Jan 28 10:17:35 test1 kernel: = partner=3D(8000,00-30-48-33-EC-44,0090,8000,0001)=0A= Jan 28 10:17:35 test1 kernel: = partner.state=3D37=0A= Jan 28 10:17:35 test1 kernel: maxdelay=3D32768=0A= Jan 28 10:17:35 test1 kernel: em0: lacp_sm_rx_update_ntt: assert ntt=0A= Jan 28 10:17:35 test1 kernel: em0: old pstate = 3d=0A= Jan 28 10:17:35 test1 kernel: em0: new pstate = bd=0A= Jan 28 10:17:35 test1 kernel: em0: lacpdu transmit=0A= Jan 28 10:17:35 test1 kernel: = actor=3D(8000,00-30-48-33-EC-44,0090,8000,0001)=0A= Jan 28 10:17:35 test1 kernel: = actor.state=3D3d=0A= Jan 28 10:17:35 test1 kernel: = partner=3D(8000,00-0A-8B-9B-CC-00,0002,8000,0323)=0A= Jan 28 10:17:35 test1 kernel: = partner.state=3Dbd=0A= Jan 28 10:17:35 test1 kernel: maxdelay=3D0=0A= Jan 28 10:17:35 test1 kernel: em0: lacpdu receive=0A= Jan 28 10:17:35 test1 kernel: = actor=3D(8000,00-0A-8B-9B-CC-00,0002,8000,0323)=0A= Jan 28 10:17:35 test1 kernel: = actor.state=3D8f=0A= Jan 28 10:17:35 test1 kernel: = partner=3D(8000,00-30-48-33-EC-44,0090,8000,0001)=0A= Jan 28 10:17:35 test1 kernel: = partner.state=3D37=0A= Jan 28 10:17:35 test1 kernel: maxdelay=3D32768=0A= Jan 28 10:17:35 test1 kernel: em0: lacp_sm_rx_update_ntt: assert ntt=0A= Jan 28 10:17:35 test1 kernel: em0: old pstate = bd=0A= Jan 28 10:17:35 test1 kernel: em0: new pstate = 8f=0A= Jan 28 10:17:35 test1 kernel: em0: partner timeout changed=0A= Jan 28 10:17:35 test1 kernel: em0: lacpdu transmit=0A= Jan 28 10:17:35 test1 kernel: = actor=3D(8000,00-30-48-33-EC-44,0090,8000,0001)=0A= Jan 28 10:17:35 test1 kernel: = actor.state=3D3d=0A= Jan 28 10:17:35 test1 kernel: = partner=3D(8000,00-0A-8B-9B-CC-00,0002,8000,0323)=0A= Jan 28 10:17:35 test1 kernel: = partner.state=3D8f=0A= Jan 28 10:17:35 test1 kernel: maxdelay=3D0=0A= Jan 28 10:17:35 test1 kernel: em0: lacpdu receive=0A= Jan 28 10:17:35 test1 kernel: = actor=3D(8000,00-0A-8B-9B-CC-00,0002,8000,0323)=0A= Jan 28 10:17:35 test1 kernel: = actor.state=3D3d=0A= Jan 28 10:17:35 test1 kernel: = partner=3D(8000,00-30-48-33-EC-44,0090,8000,0001)=0A= Jan 28 10:17:35 test1 kernel: = partner.state=3D3d=0A= Jan 28 10:17:35 test1 kernel: maxdelay=3D32768=0A= Jan 28 10:17:35 test1 kernel: em0: old pstate = 8f=0A= Jan 28 10:17:35 test1 kernel: em0: new pstate = 3d=0A= Jan 28 10:17:35 test1 kernel: em0: partner timeout changed=0A= Jan 28 10:17:35 test1 kernel: em0: lacpdu receive=0A= Jan 28 10:17:35 test1 kernel: = actor=3D(8000,00-0A-8B-9B-CC-00,0002,8000,0323)=0A= Jan 28 10:17:35 test1 kernel: actor.state=3D1=0A= Jan 28 10:17:35 test1 kernel: = partner=3D(8000,00-30-48-33-EC-44,0090,8000,0001)=0A= Jan 28 10:17:35 test1 kernel: = partner.state=3D3d=0A= Jan 28 10:17:35 test1 kernel: maxdelay=3D32768=0A= Jan 28 10:17:35 test1 kernel: em0: old pstate = 3d=0A= Jan 28 10:17:35 test1 kernel: em0: new pstate 1=0A= Jan 28 10:17:35 test1 kernel: em0: collecting enabled=0A= Jan 28 10:17:35 test1 kernel: em0: disable distributing on aggregator = [(8000,00-30-48-33-EC-44,0090,0000,0000),(8000,00-0A-8B-9B-CC-00,0002,000= 0,0000)], nports 2 -> 1=0A= Jan 28 10:17:35 test1 kernel: lacp_suppress_distributing=0A= Jan 28 10:17:35 test1 kernel: em1: marker transmit, port=3D2, = sys=3D00:30:48:33:ec:44, id=3D3=0A= Jan 28 10:17:35 test1 kernel: em0: marker transmit, port=3D1, = sys=3D00:30:48:33:ec:44, id=3D3=0A= Jan 28 10:17:35 test1 kernel: lacp_select_active_aggregator:=0A= Jan 28 10:17:35 test1 kernel: = [(8000,00-30-48-33-EC-44,0090,0000,0000),(8000,00-0A-8B-9B-CC-00,0002,000= 0,0000)], speed=3D1000000000, nports=3D1=0A= Jan 28 10:17:35 test1 kernel: active aggregator not changed=0A= Jan 28 10:17:35 test1 kernel: new = [(8000,00-30-48-33-EC-44,0090,0000,0000),(8000,00-0A-8B-9B-CC-00,0002,000= 0,0000)]=0A= Jan 28 10:17:35 test1 kernel: Set table 1 with 1 ports=0A= Jan 28 10:17:35 test1 kernel: em0: mux_state 4 -> 3=0A= Jan 28 10:17:35 test1 kernel: em0: collecting disabled=0A= Jan 28 10:17:35 test1 kernel: em0: mux_state 3 -> 2=0A= Jan 28 10:17:35 test1 kernel: em0: collecting disabled=0A= Jan 28 10:17:35 test1 kernel: lacp_aggregator_delref: = lagid=3D[(8000,00-30-48-33-EC-44,0090,0000,0000),(8000,00-0A-8B-9B-CC-00,= 0002,0000,0000)], refcnt 2 -> 1=0A= Jan 28 10:17:35 test1 kernel: em0: mux_state 2 -> 0=0A= Jan 28 10:17:35 test1 kernel: em0: rate limited pdu=0A= Jan 28 10:17:35 test1 kernel: em1: marker response, port=3D2, = sys=3D00:30:48:33:ec:44, id=3D3=0A= Jan 28 10:17:35 test1 kernel: em0: media changed 0x100030 -> 0x20, ether = =3D 1, fdx =3D 0, link =3D 0=0A= Jan 28 10:17:35 test1 kernel: em0: -> UNSELECTED=0A= Jan 28 10:17:35 test1 kernel: em0: link state changed to DOWN=0A= Jan 28 10:17:35 test1 kernel: em1: lacpdu receive=0A= Jan 28 10:17:35 test1 kernel: = actor=3D(8000,00-0A-8B-9B-CC-00,0002,8000,032B)=0A= Jan 28 10:17:35 test1 kernel: = actor.state=3Dbd=0A= Jan 28 10:17:35 test1 kernel: = partner=3D(8000,00-30-48-33-EC-44,0090,8000,0002)=0A= Jan 28 10:17:35 test1 kernel: = partner.state=3D37=0A= Jan 28 10:17:35 test1 kernel: maxdelay=3D32768=0A= Jan 28 10:17:35 test1 kernel: em1: lacp_sm_rx_update_ntt: assert ntt=0A= Jan 28 10:17:35 test1 kernel: em1: old pstate = 3d=0A= Jan 28 10:17:35 test1 kernel: em1: new pstate = bd=0A= Jan 28 10:17:35 test1 kernel: em1: lacpdu transmit=0A= Jan 28 10:17:35 test1 kernel: = actor=3D(8000,00-30-48-33-EC-44,0090,8000,0002)=0A= Jan 28 10:17:35 test1 kernel: = actor.state=3D3d=0A= Jan 28 10:17:35 test1 kernel: = partner=3D(8000,00-0A-8B-9B-CC-00,0002,8000,032B)=0A= Jan 28 10:17:35 test1 kernel: = partner.state=3Dbd=0A= Jan 28 10:17:35 test1 kernel: maxdelay=3D0=0A= Jan 28 10:17:35 test1 kernel: em1: lacpdu receive=0A= Jan 28 10:17:35 test1 kernel: = actor=3D(8000,00-0A-8B-9B-CC-00,0002,8000,032B)=0A= Jan 28 10:17:35 test1 kernel: = actor.state=3D8f=0A= Jan 28 10:17:35 test1 kernel: = partner=3D(8000,00-30-48-33-EC-44,0090,8000,0002)=0A= Jan 28 10:17:35 test1 kernel: = partner.state=3D37=0A= Jan 28 10:17:35 test1 kernel: maxdelay=3D32768=0A= Jan 28 10:17:35 test1 kernel: em1: lacp_sm_rx_update_ntt: assert ntt=0A= Jan 28 10:17:35 test1 kernel: em1: old pstate = bd=0A= Jan 28 10:17:35 test1 kernel: em1: new pstate = 8f=0A= Jan 28 10:17:35 test1 kernel: em1: partner timeout changed=0A= Jan 28 10:17:35 test1 kernel: em1: lacpdu transmit=0A= Jan 28 10:17:35 test1 kernel: =0A= Jan 28 10:17:35 test1 kernel: = actor=3D(8000,00-30-48-33-EC-44,0090,8000,0002)=0A= Jan 28 10:17:35 test1 kernel: = actor.state=3D3d=0A= Jan 28 10:17:36 test1 kernel: =0A= Jan 28 10:17:36 test1 kernel: = partner=3D(8000,00-0A-8B-9B-CC-00,0002,8000,032B)=0A= Jan 28 10:17:36 test1 kernel: = partner.state=3D8f=0A= Jan 28 10:17:36 test1 kernel: maxdelay=3D0=0A= Jan 28 10:17:36 test1 kernel: em1: lacpdu receive=0A= Jan 28 10:17:36 test1 kernel: = actor=3D(8000,00-0A-8B-9B-CC-00,0002,8000,032B)=0A= Jan 28 10:17:36 test1 kernel: = actor.state=3D3d=0A= Jan 28 10:17:36 test1 kernel: = partner=3D(8000,00-30-48-33-EC-44,0090,8000,0002)=0A= Jan 28 10:17:36 test1 kernel: = partner.state=3D3d=0A= Jan 28 10:17:36 test1 kernel: maxdelay=3D32768=0A= Jan 28 10:17:36 test1 kernel: em1: old pstate = 8f=0A= Jan 28 10:17:36 test1 kernel: em1: new pstate = 3d=0A= Jan 28 10:17:36 test1 kernel: em1: partner timeout changed=0A= Jan 28 10:17:36 test1 kernel: em1: lacpdu receive=0A= Jan 28 10:17:36 test1 kernel: = actor=3D(8000,00-0A-8B-9B-CC-00,0002,8000,032B)=0A= Jan 28 10:17:36 test1 kernel: actor.state=3D1=0A= Jan 28 10:17:36 test1 kernel: = partner=3D(8000,00-30-48-33-EC-44,0090,8000,0002)=0A= Jan 28 10:17:36 test1 kernel: = partner.state=3D3d=0A= Jan 28 10:17:36 test1 kernel: maxdelay=3D32768=0A= Jan 28 10:17:36 test1 kernel: em1: old pstate = 3d=0A= Jan 28 10:17:36 test1 kernel: em1: new pstate 1=0A= Jan 28 10:17:36 test1 kernel: em1: media changed 0x100030 -> 0x20, ether = =3D 1, fdx =3D 0, link =3D 0=0A= Jan 28 10:17:36 test1 kernel: em1: disable distributing on aggregator = [(8000,00-30-48-33-EC-44,0090,0000,0000),(8000,00-0A-8B-9B-CC-00,0002,000= 0,0000)], nports 1 -> 0=0A= Jan 28 10:17:36 test1 kernel: lacp_suppress_distributing=0A= Jan 28 10:17:36 test1 kernel: em1: marker transmit, port=3D2, = sys=3D00:30:48:33:ec:44, id=3D4=0A= Jan 28 10:17:36 test1 kernel: em0: marker transmit, port=3D1, = sys=3D00:30:48:33:ec:44, id=3D4=0A= Jan 28 10:17:36 test1 kernel: lacp_select_active_aggregator:=0A= Jan 28 10:17:36 test1 kernel: active aggregator changed=0A= Jan 28 10:17:36 test1 kernel: old = [(8000,00-30-48-33-EC-44,0090,0000,0000),(8000,00-0A-8B-9B-CC-00,0002,000= 0,0000)]=0A= Jan 28 10:17:36 test1 kernel: new (none)=0A= Jan 28 10:17:36 test1 kernel: Set table 0 with 0 ports=0A= Jan 28 10:17:36 test1 kernel: Set table 1 with 0 ports=0A= Jan 28 10:17:36 test1 kernel: em1: collecting disabled=0A= Jan 28 10:17:36 test1 kernel: lacp_aggregator_delref: = lagid=3D[(8000,00-30-48-33-EC-44,0090,0000,0000),(8000,00-0A-8B-9B-CC-00,= 0002,0000,0000)], refcnt 1 -> 0=0A= Jan 28 10:17:36 test1 kernel: em1: mux_state 4 -> 0=0A= Jan 28 10:17:36 test1 kernel: em1: -> UNSELECTED=0A= Jan 28 10:17:36 test1 kernel: em1: link state changed to DOWN=0A= Jan 28 10:17:36 test1 kernel: lagg0: link state changed to DOWN=0A= Jan 28 10:17:39 test1 kernel: lacp_transit_expire=0A= Jan 28 10:18:50 test1 login: ROOT LOGIN (root) ON ttyv0=0A= Jan 28 10:25:10 test1 kernel: em0: media changed 0x20 -> 0x100030, ether = =3D 1, fdx =3D 1, link =3D 1=0A= Jan 28 10:25:10 test1 kernel: em0: -> UNSELECTED=0A= Jan 28 10:25:10 test1 kernel: em0: link state changed to UP=0A= Jan 28 10:25:10 test1 kernel: lagg0: link state changed to UP=0A= Jan 28 10:25:11 test1 kernel: em0: port = lagid=3D[(8000,00-30-48-33-EC-44,0090,8000,0001),(FFFF,00-00-00-00-00-00,= 0000,FFFF,0000)]=0A= Jan 28 10:25:11 test1 kernel: em0: aggregator created=0A= Jan 28 10:25:11 test1 kernel: em0: aggregator = lagid=3D[(8000,00-30-48-33-EC-44,0090,0000,0000),(FFFF,00-00-00-00-00-00,= 0000,0000,0000)]=0A= Jan 28 10:25:11 test1 kernel: em0: mux_state 0 -> 1=0A= Jan 28 10:25:11 test1 kernel: em0: lacpdu transmit=0A= Jan 28 10:25:11 test1 kernel: = actor=3D(8000,00-30-48-33-EC-44,0090,8000,0001)=0A= Jan 28 10:25:11 test1 kernel: = actor.state=3D45=0A= Jan 28 10:25:11 test1 kernel: = partner=3D(FFFF,00-00-00-00-00-00,0000,FFFF,0000)=0A= Jan 28 10:25:11 test1 kernel: = partner.state=3D38=0A= Jan 28 10:25:11 test1 kernel: maxdelay=3D0=0A= Jan 28 10:25:11 test1 kernel: em0: lacpdu receive=0A= Jan 28 10:25:11 test1 kernel: = actor=3D(8000,00-0A-8B-9B-CC-00,0002,8000,0323)=0A= Jan 28 10:25:11 test1 kernel: = actor.state=3D7=0A= Jan 28 10:25:11 test1 kernel: = partner=3D(8000,00-30-48-33-EC-44,0090,8000,0001)=0A= Jan 28 10:25:11 test1 kernel: = partner.state=3D45=0A= Jan 28 10:25:11 test1 kernel: maxdelay=3D32768=0A= Jan 28 10:25:11 test1 kernel: em0: old pstate = 38=0A= Jan 28 10:25:11 test1 kernel: em0: new pstate = 7=0A= Jan 28 10:25:11 test1 kernel: em0: partner timeout changed=0A= Jan 28 10:25:11 test1 kernel: em0: lacpdu transmit=0A= Jan 28 10:25:11 test1 kernel: = actor=3D(8000,00-30-48-33-EC-44,0090,8000,0001)=0A= Jan 28 10:25:11 test1 kernel: actor.state=3D5=0A= Jan 28 10:25:11 test1 kernel: = partner=3D(8000,00-0A-8B-9B-CC-00,0002,8000,0323)=0A= Jan 28 10:25:11 test1 kernel: = partner.state=3D7=0A= Jan 28 10:25:11 test1 kernel: maxdelay=3D0=0A= Jan 28 10:25:12 test1 kernel: em0: collecting disabled=0A= Jan 28 10:25:12 test1 kernel: lacp_aggregator_delref: = lagid=3D[(8000,00-30-48-33-EC-44,0090,0000,0000),(FFFF,00-00-00-00-00-00,= 0000,0000,0000)], refcnt 1 -> 0=0A= Jan 28 10:25:12 test1 kernel: em0: mux_state 1 -> 0=0A= Jan 28 10:25:12 test1 kernel: em0: lacpdu transmit=0A= Jan 28 10:25:12 test1 kernel: = actor=3D(8000,00-30-48-33-EC-44,0090,8000,0001)=0A= Jan 28 10:25:12 test1 kernel: actor.state=3D5=0A= Jan 28 10:25:12 test1 kernel: = partner=3D(8000,00-0A-8B-9B-CC-00,0002,8000,0323)=0A= Jan 28 10:25:12 test1 kernel: = partner.state=3D7=0A= Jan 28 10:25:12 test1 kernel: maxdelay=3D0=0A= Jan 28 10:25:12 test1 kernel: em0: lacpdu receive=0A= Jan 28 10:25:12 test1 kernel: = actor=3D(8000,00-0A-8B-9B-CC-00,0002,8000,0323)=0A= Jan 28 10:25:12 test1 kernel: = actor.state=3Df=0A= Jan 28 10:25:12 test1 kernel: = partner=3D(8000,00-30-48-33-EC-44,0090,8000,0001)=0A= Jan 28 10:25:12 test1 kernel: partner.state=3D5=0A= Jan 28 10:25:12 test1 kernel: maxdelay=3D32768=0A= Jan 28 10:25:12 test1 kernel: em0: old pstate = 7=0A= Jan 28 10:25:12 test1 kernel: em0: new pstate = f=0A= Jan 28 10:25:13 test1 kernel: em0: port = lagid=3D[(8000,00-30-48-33-EC-44,0090,8000,0001),(8000,00-0A-8B-9B-CC-00,= 0002,8000,0323)]=0A= Jan 28 10:25:13 test1 kernel: em0: aggregator created=0A= Jan 28 10:25:13 test1 kernel: em0: aggregator = lagid=3D[(8000,00-30-48-33-EC-44,0090,0000,0000),(8000,00-0A-8B-9B-CC-00,= 0002,0000,0000)]=0A= Jan 28 10:25:13 test1 kernel: em0: mux_state 0 -> 1=0A= Jan 28 10:25:13 test1 kernel: em0: lacpdu transmit=0A= Jan 28 10:25:13 test1 kernel: = actor=3D(8000,00-30-48-33-EC-44,0090,8000,0001)=0A= Jan 28 10:25:13 test1 kernel: actor.state=3D5=0A= Jan 28 10:25:13 test1 kernel: = partner=3D(8000,00-0A-8B-9B-CC-00,0002,8000,0323)=0A= Jan 28 10:25:13 test1 kernel: = partner.state=3Df=0A= Jan 28 10:25:13 test1 kernel: maxdelay=3D0=0A= Jan 28 10:25:14 test1 kernel: em0: lacpdu transmit=0A= Jan 28 10:25:14 test1 kernel: = actor=3D(8000,00-30-48-33-EC-44,0090,8000,0001)=0A= Jan 28 10:25:14 test1 kernel: actor.state=3D5=0A= Jan 28 10:25:14 test1 kernel: = partner=3D(8000,00-0A-8B-9B-CC-00,0002,8000,0323)=0A= Jan 28 10:25:14 test1 kernel: = partner.state=3Df=0A= Jan 28 10:25:14 test1 kernel: maxdelay=3D0=0A= Jan 28 10:25:15 test1 kernel: em0: lacp_sm_mux_timer: aggregator = [(8000,00-30-48-33-EC-44,0090,0000,0000),(8000,00-0A-8B-9B-CC-00,0002,000= 0,0000)], pending 1 -> 0=0A= Jan 28 10:25:15 test1 kernel: em0: collecting disabled=0A= Jan 28 10:25:15 test1 kernel: em0: mux_state 1 -> 2=0A= Jan 28 10:25:15 test1 kernel: em0: collecting enabled=0A= Jan 28 10:25:15 test1 kernel: em0: mux_state 2 -> 3=0A= Jan 28 10:25:15 test1 kernel: em0: lacpdu transmit=0A= Jan 28 10:25:15 test1 kernel: = actor=3D(8000,00-30-48-33-EC-44,0090,8000,0001)=0A= Jan 28 10:25:15 test1 kernel: = actor.state=3D1d=0A= Jan 28 10:25:15 test1 kernel: = partner=3D(8000,00-0A-8B-9B-CC-00,0002,8000,0323)=0A= Jan 28 10:25:15 test1 kernel: = partner.state=3Df=0A= Jan 28 10:25:15 test1 kernel: maxdelay=3D0=0A= Jan 28 10:25:15 test1 kernel: em0: lacpdu receive=0A= Jan 28 10:25:15 test1 kernel: = actor=3D(8000,00-0A-8B-9B-CC-00,0002,8000,0323)=0A= Jan 28 10:25:15 test1 kernel: = actor.state=3D3d=0A= Jan 28 10:25:15 test1 kernel: = partner=3D(8000,00-30-48-33-EC-44,0090,8000,0001)=0A= Jan 28 10:25:15 test1 kernel: = partner.state=3D1d=0A= Jan 28 10:25:15 test1 kernel: maxdelay=3D32768=0A= Jan 28 10:25:15 test1 kernel: em0: old pstate = f=0A= Jan 28 10:25:15 test1 kernel: em0: new pstate = 3d=0A= Jan 28 10:25:15 test1 kernel: em0: partner timeout changed=0A= Jan 28 10:25:16 test1 kernel: em0: enable distributing on aggregator = [(8000,00-30-48-33-EC-44,0090,0000,0000),(8000,00-0A-8B-9B-CC-00,0002,000= 0,0000)], nports 0 -> 1=0A= Jan 28 10:25:16 test1 kernel: lacp_select_active_aggregator:=0A= Jan 28 10:25:16 test1 kernel: = [(8000,00-30-48-33-EC-44,0090,0000,0000),(8000,00-0A-8B-9B-CC-00,0002,000= 0,0000)], speed=3D1000000000, nports=3D1=0A= Jan 28 10:25:16 test1 kernel: active aggregator changed=0A= Jan 28 10:25:16 test1 kernel: old (none)=0A= Jan 28 10:25:16 test1 kernel: new = [(8000,00-30-48-33-EC-44,0090,0000,0000),(8000,00-0A-8B-9B-CC-00,0002,000= 0,0000)]=0A= Jan 28 10:25:16 test1 kernel: Set table 0 with 1 ports=0A= Jan 28 10:25:16 test1 kernel: lacp_suppress_distributing=0A= Jan 28 10:25:16 test1 kernel: em1: marker transmit, port=3D2, = sys=3D00:30:48:33:ec:44, id=3D5=0A= Jan 28 10:25:16 test1 kernel: em0: marker transmit, port=3D1, = sys=3D00:30:48:33:ec:44, id=3D5=0A= Jan 28 10:25:16 test1 kernel: em0: mux_state 3 -> 4em0: =0A= Jan 28 10:25:16 test1 kernel: marker response, port=3D1, = sys=3D00:30:48:33:ec:44, id=3D5=0A= Jan 28 10:25:17 test1 kernel: em0: lacpdu receive=0A= Jan 28 10:25:17 test1 kernel: = actor=3D(8000,00-0A-8B-9B-CC-00,0002,8000,0323)=0A= Jan 28 10:25:17 test1 kernel: = actor.state=3Dbd=0A= Jan 28 10:25:17 test1 kernel: = partner=3D(8000,00-30-48-33-EC-44,0090,8000,0001)=0A= Jan 28 10:25:17 test1 kernel: = partner.state=3D17=0A= Jan 28 10:25:17 test1 kernel: maxdelay=3D32768=0A= Jan 28 10:25:17 test1 kernel: em0: lacp_sm_rx_update_ntt: assert ntt=0A= Jan 28 10:25:17 test1 kernel: em0: old pstate = 3d=0A= Jan 28 10:25:17 test1 kernel: em0: new pstate = bd=0A= Jan 28 10:25:17 test1 kernel: em0: lacpdu transmit=0A= Jan 28 10:25:17 test1 kernel: = actor=3D(8000,00-30-48-33-EC-44,0090,8000,0001)=0A= Jan 28 10:25:17 test1 kernel: = actor.state=3D3d=0A= Jan 28 10:25:17 test1 kernel: = partner=3D(8000,00-0A-8B-9B-CC-00,0002,8000,0323)=0A= Jan 28 10:25:17 test1 kernel: = partner.state=3Dbd=0A= Jan 28 10:25:17 test1 kernel: maxdelay=3D0=0A= Jan 28 10:25:17 test1 kernel: em0: lacpdu receive=0A= Jan 28 10:25:17 test1 kernel: = actor=3D(8000,00-0A-8B-9B-CC-00,0002,8000,0323)=0A= Jan 28 10:25:17 test1 kernel: = actor.state=3D8f=0A= Jan 28 10:25:17 test1 kernel: = partner=3D(8000,00-30-48-33-EC-44,0090,8000,0001)=0A= Jan 28 10:25:17 test1 kernel: = partner.state=3D17=0A= Jan 28 10:25:17 test1 kernel: maxdelay=3D32768=0A= Jan 28 10:25:17 test1 kernel: em0: lacp_sm_rx_update_ntt: assert ntt=0A= Jan 28 10:25:17 test1 kernel: em0: old pstate = bd=0A= Jan 28 10:25:17 test1 kernel: em0: new pstate = 8f=0A= Jan 28 10:25:17 test1 kernel: em0: partner timeout changed=0A= Jan 28 10:25:17 test1 kernel: em0: lacpdu transmit=0A= Jan 28 10:25:17 test1 kernel: = actor=3D(8000,00-30-48-33-EC-44,0090,8000,0001)=0A= Jan 28 10:25:17 test1 kernel: = actor.state=3D3d=0A= Jan 28 10:25:17 test1 kernel: = partner=3D(8000,00-0A-8B-9B-CC-00,0002,8000,0323)=0A= Jan 28 10:25:17 test1 kernel: = partner.state=3D8f=0A= Jan 28 10:25:17 test1 kernel: maxdelay=3D0=0A= Jan 28 10:25:17 test1 kernel: em0: lacpdu receive=0A= Jan 28 10:25:17 test1 kernel: = actor=3D(8000,00-0A-8B-9B-CC-00,0002,8000,0323)=0A= Jan 28 10:25:17 test1 kernel: = actor.state=3D3d=0A= Jan 28 10:25:17 test1 kernel: = partner=3D(8000,00-30-48-33-EC-44,0090,8000,0001)=0A= Jan 28 10:25:17 test1 kernel: = partner.state=3D3d=0A= Jan 28 10:25:17 test1 kernel: maxdelay=3D32768=0A= Jan 28 10:25:17 test1 kernel: em0: old pstate = 8f=0A= Jan 28 10:25:17 test1 kernel: em0: new pstate = 3d=0A= Jan 28 10:25:17 test1 kernel: em0: partner timeout changed=0A= Jan 28 10:25:19 test1 kernel: lacp_transit_expire=0A= Jan 28 10:25:20 test1 kernel: em0: lacpdu receive=0A= Jan 28 10:25:20 test1 kernel: = actor=3D(8000,00-0A-8B-9B-CC-00,0002,8000,0323)=0A= Jan 28 10:25:20 test1 kernel: = actor.state=3Dbd=0A= Jan 28 10:25:20 test1 kernel: = partner=3D(8000,00-30-48-33-EC-44,0090,8000,0001)=0A= Jan 28 10:25:20 test1 kernel: = partner.state=3D37=0A= Jan 28 10:25:20 test1 kernel: maxdelay=3D32768=0A= Jan 28 10:25:20 test1 kernel: em0: lacp_sm_rx_update_ntt: assert ntt=0A= Jan 28 10:25:20 test1 kernel: em0: old pstate = 3d=0A= Jan 28 10:25:20 test1 kernel: em0: new pstate = bd=0A= Jan 28 10:25:20 test1 kernel: em0: lacpdu transmit=0A= Jan 28 10:25:20 test1 kernel: = actor=3D(8000,00-30-48-33-EC-44,0090,8000,0001)=0A= Jan 28 10:25:20 test1 kernel: = actor.state=3D3d=0A= Jan 28 10:25:20 test1 kernel: = partner=3D(8000,00-0A-8B-9B-CC-00,0002,8000,0323)=0A= Jan 28 10:25:20 test1 kernel: = partner.state=3Dbd=0A= Jan 28 10:25:20 test1 kernel: maxdelay=3D0=0A= Jan 28 10:25:20 test1 kernel: em0: lacpdu receive=0A= Jan 28 10:25:20 test1 kernel: = actor=3D(8000,00-0A-8B-9B-CC-00,0002,8000,0323)=0A= Jan 28 10:25:20 test1 kernel: = actor.state=3D8f=0A= Jan 28 10:25:20 test1 kernel: = partner=3D(8000,00-30-48-33-EC-44,0090,8000,0001)=0A= Jan 28 10:25:20 test1 kernel: =0A= Jan 28 10:25:20 test1 kernel: = partner.state=3D37=0A= Jan 28 10:25:20 test1 kernel: maxdelay=3D32768=0A= Jan 28 10:25:20 test1 kernel: em0: lacp_sm_rx_update_ntt: assert ntt=0A= Jan 28 10:25:20 test1 kernel: em0: old pstate = bd=0A= Jan 28 10:25:20 test1 kernel: em0: new pstate = 8f=0A= Jan 28 10:25:20 test1 kernel: em0: partner timeout changed=0A= Jan 28 10:25:20 test1 kernel: em0: lacpdu transmit=0A= Jan 28 10:25:20 test1 kernel: = actor=3D(8000,00-30-48-33-EC-44,0090,8000,0001)=0A= Jan 28 10:25:20 test1 kernel: = actor.state=3D3d=0A= Jan 28 10:25:20 test1 kernel: = partner=3D(8000,00-0A-8B-9B-CC-00,0002,8000,0323)=0A= Jan 28 10:25:20 test1 kernel: = partner.state=3D8f=0A= Jan 28 10:25:20 test1 kernel: maxdelay=3D0=0A= Jan 28 10:25:20 test1 kernel: em0: lacpdu receive=0A= Jan 28 10:25:20 test1 kernel: = actor=3D(8000,00-0A-8B-9B-CC-00,0002,8000,0323)=0A= Jan 28 10:25:20 test1 kernel: = actor.state=3D3d=0A= Jan 28 10:25:20 test1 kernel: = partner=3D(8000,00-30-48-33-EC-44,0090,8000,0001)=0A= Jan 28 10:25:20 test1 kernel: = partner.state=3D3d=0A= Jan 28 10:25:20 test1 kernel: maxdelay=3D32768=0A= Jan 28 10:25:20 test1 kernel: em0: old pstate = 8f=0A= Jan 28 10:25:20 test1 kernel: em0: new pstate = 3d=0A= Jan 28 10:25:20 test1 kernel: em0: partner timeout changed=0A= Jan 28 10:25:23 test1 kernel: em0: lacpdu receive=0A= Jan 28 10:25:23 test1 kernel: = actor=3D(8000,00-0A-8B-9B-CC-00,0002,8000,0323)=0A= Jan 28 10:25:23 test1 kernel: = actor.state=3Dbd=0A= Jan 28 10:25:23 test1 kernel: = partner=3D(8000,00-30-48-33-EC-44,0090,8000,0001)=0A= Jan 28 10:25:23 test1 kernel: = partner.state=3D37=0A= Jan 28 10:25:23 test1 kernel: maxdelay=3D32768=0A= Jan 28 10:25:23 test1 kernel: em0: lacp_sm_rx_update_ntt: assert ntt=0A= Jan 28 10:25:23 test1 kernel: em0: old pstate = 3d=0A= Jan 28 10:25:23 test1 kernel: em0: new pstate = bd=0A= Jan 28 10:25:23 test1 kernel: em0: lacpdu transmit=0A= Jan 28 10:25:23 test1 kernel: = actor=3D(8000,00-30-48-33-EC-44,0090,8000,0001)=0A= Jan 28 10:25:23 test1 kernel: = actor.state=3D3d=0A= Jan 28 10:25:23 test1 kernel: = partner=3D(8000,00-0A-8B-9B-CC-00,0002,8000,0323)=0A= Jan 28 10:25:23 test1 kernel: = partner.state=3Dbd=0A= Jan 28 10:25:23 test1 kernel: maxdelay=3D0=0A= Jan 28 10:25:23 test1 kernel: em0: lacpdu receive=0A= Jan 28 10:25:23 test1 kernel: = actor=3D(8000,00-0A-8B-9B-CC-00,0002,8000,0323)=0A= Jan 28 10:25:23 test1 kernel: = actor.state=3D8f=0A= Jan 28 10:25:23 test1 kernel: = partner=3D(8000,00-30-48-33-EC-44,0090,8000,0001)=0A= Jan 28 10:25:23 test1 kernel: = partner.state=3D37=0A= Jan 28 10:25:23 test1 kernel: maxdelay=3D32768=0A= Jan 28 10:25:23 test1 kernel: em0: lacp_sm_rx_update_ntt: assert ntt=0A= Jan 28 10:25:23 test1 kernel: em0: old pstate = bd=0A= Jan 28 10:25:23 test1 kernel: em0: new pstate = 8f=0A= Jan 28 10:25:23 test1 kernel: em0: partner timeout changed=0A= Jan 28 10:25:23 test1 kernel: em0: lacpdu transmit=0A= Jan 28 10:25:23 test1 kernel: = actor=3D(8000,00-30-48-33-EC-44,0090,8000,0001)=0A= Jan 28 10:25:23 test1 kernel: = actor.state=3D3d=0A= Jan 28 10:25:23 test1 kernel: = partner=3D(8000,00-0A-8B-9B-CC-00,0002,8000,0323)=0A= Jan 28 10:25:23 test1 kernel: = partner.state=3D8f=0A= Jan 28 10:25:23 test1 kernel: maxdelay=3D0=0A= Jan 28 10:25:23 test1 kernel: em0: lacpdu receive=0A= Jan 28 10:25:23 test1 kernel: = actor=3D(8000,00-0A-8B-9B-CC-00,0002,8000,0323)=0A= Jan 28 10:25:23 test1 kernel: = actor.state=3D3d=0A= Jan 28 10:25:23 test1 kernel: = partner=3D(8000,00-30-48-33-EC-44,0090,8000,0001)=0A= Jan 28 10:25:23 test1 kernel: = partner.state=3D3d=0A= Jan 28 10:25:23 test1 kernel: maxdelay=3D32768=0A= Jan 28 10:25:23 test1 kernel: em0: old pstate = 8f=0A= Jan 28 10:25:23 test1 kernel: em0: new pstate = 3d=0A= Jan 28 10:25:23 test1 kernel: em0: partner timeout changed=0A= Jan 28 10:25:23 test1 kernel: em0: media changed 0x100030 -> 0x20, ether = =3D 1, fdx =3D 0, link =3D 0=0A= Jan 28 10:25:23 test1 kernel: em0: disable distributing on aggregator = [(8000,00-30-48-33-EC-44,0090,0000,0000),(8000,00-0A-8B-9B-CC-00,0002,000= 0,0000)], nports 1 -> 0=0A= Jan 28 10:25:23 test1 kernel: lacp_suppress_distributing=0A= Jan 28 10:25:23 test1 kernel: em1: marker transmit, port=3D2, = sys=3D00:30:48:33:ec:44, id=3D6=0A= Jan 28 10:25:23 test1 kernel: em0: marker transmit, port=3D1, = sys=3D00:30:48:33:ec:44, id=3D6=0A= Jan 28 10:25:23 test1 kernel: lacp_select_active_aggregator:=0A= Jan 28 10:25:23 test1 kernel: active aggregator changed=0A= Jan 28 10:25:23 test1 kernel: old = [(8000,00-30-48-33-EC-44,0090,0000,0000),(8000,00-0A-8B-9B-CC-00,0002,000= 0,0000)]=0A= Jan 28 10:25:23 test1 kernel: new (none)=0A= Jan 28 10:25:23 test1 kernel: Set table 1 with 0 ports=0A= Jan 28 10:25:23 test1 kernel: Set table 0 with 0 ports=0A= Jan 28 10:25:23 test1 kernel: em0: collecting disabled=0A= Jan 28 10:25:23 test1 kernel: lacp_aggregator_delref: = lagid=3D[(8000,00-30-48-33-EC-44,0090,0000,0000),(8000,00-0A-8B-9B-CC-00,= 0002,0000,0000)], refcnt 1 -> 0=0A= Jan 28 10:25:23 test1 kernel: em0: mux_state 4 -> 0=0A= Jan 28 10:25:23 test1 kernel: em0: -> UNSELECTED=0A= Jan 28 10:25:23 test1 kernel: em0: link state changed to DOWN=0A= Jan 28 10:25:23 test1 kernel: lagg0: link state changed to DOWN=0A= Jan 28 10:25:26 test1 kernel: lacp_transit_expire=0A= ------=_NextPart_000_0045_01CAA00A.A9FB0D40-- From owner-freebsd-net@FreeBSD.ORG Thu Jan 28 12:23:49 2010 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 542C31065676 for ; Thu, 28 Jan 2010 12:23:49 +0000 (UTC) (envelope-from balajig81@gmail.com) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by mx1.freebsd.org (Postfix) with ESMTP id 2E8E18FC13 for ; Thu, 28 Jan 2010 12:23:48 +0000 (UTC) Received: by pwi15 with SMTP id 15so459608pwi.3 for ; Thu, 28 Jan 2010 04:23:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=a8IqoN2UgMTo3WZjxNChzzUhNvAvYgo05CNyTHzCg1g=; b=h0h18/fMDeyhCg2wOElrSnUU/BSIHh5X9s2K0Ts3SsGr8V/kxioD1zb2stL5oEuvtt g8iXwiD7hSMDaaxDF7QJ+ZXlHdtarvqMIOOta71kUesfUS5nGtzcGulQdgzUR7CMpMcY IWz9yGB8En17AN0Tjh7D4xXxbRc2YDIAqQRSU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=tqW3HrwWAbhS33qiMCa/4GImk/UTVGNugmu86N+r0rPZ50NuSWUG7fc8UwOwFodsXS cn+gYlLh37EE5gKUKHt+IQOEfEUv3VRWdSX0giDAhtbrHmCrrGJV9RQluPwPg/o6yX6L swLThc1p6hg80B1MDOWdxcabgW38pL380gXbc= MIME-Version: 1.0 Received: by 10.142.120.26 with SMTP id s26mr1244369wfc.157.1264679776998; Thu, 28 Jan 2010 03:56:16 -0800 (PST) Date: Thu, 28 Jan 2010 17:26:16 +0530 Message-ID: <6dd1343e1001280356u77e4d1f3wfe668da2970e62e7@mail.gmail.com> From: Balaji G To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: ECMP support in FreeBSD 7.2 and 8.0 + 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, 28 Jan 2010 12:23:49 -0000 Hi Everybody I would like to know whether ECMP feature is supported in FreeBSD 7.2. I was able to infer that ECMP is supported in FreeBSD 8.0 because i was able to look into the SVN checkin logs and also found out that in FreeBSD 8.0 the ECMP code was wrapped under RADIX_MPATH macro. I was not able to get any results when i did a search for RADIX_MPATH in 7.2. I would like to know whether ECMP code exists in 7.2 and whether it provides the same functionality as given in FreeBSD 8.0 Thanks for your time. Cheers, - Balaji From owner-freebsd-net@FreeBSD.ORG Thu Jan 28 13:40:39 2010 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 97400106566B; Thu, 28 Jan 2010 13:40:39 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 540418FC08; Thu, 28 Jan 2010 13:40:37 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA19216; Thu, 28 Jan 2010 15:40:26 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4B6193CA.1040702@icyb.net.ua> Date: Thu, 28 Jan 2010 15:40:26 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20091206) MIME-Version: 1.0 To: sam References: <7f14551c1001231916s1c142b21j916ae406ea71bd97@mail.gmail.com> <4B60E157.9090200@ip6.com.au> <7f14551c1001271805w758c3e95s569365ad468ab9ae@mail.gmail.com> <4B60FE95.7040209@ip6.com.au> In-Reply-To: <4B60FE95.7040209@ip6.com.au> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Sherin George , freebsd-hackers@freebsd.org, freebsd-questions@freebsd.org Subject: Re: Strange network issue in freebsd 8 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, 28 Jan 2010 13:40:39 -0000 on 28/01/2010 05:03 sam said the following: > that s why I 've been so in doubt using freebsd AMD64 release. Why again? -- Andriy Gapon From owner-freebsd-net@FreeBSD.ORG Thu Jan 28 16:32:54 2010 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 5D1DE106566C for ; Thu, 28 Jan 2010 16:32:54 +0000 (UTC) (envelope-from tiffolk@gmail.com) Received: from mail-yw0-f194.google.com (mail-yw0-f194.google.com [209.85.211.194]) by mx1.freebsd.org (Postfix) with ESMTP id 11FA68FC1C for ; Thu, 28 Jan 2010 16:32:53 +0000 (UTC) Received: by ywh32 with SMTP id 32so157937ywh.14 for ; Thu, 28 Jan 2010 08:32:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=Y3/DAqhINvPOXMksVo+8Dc6V/0MiqByUXmDeN5qX6Uk=; b=hxboD8TukN5bb2nb7x4cV56euFoy9N3u2zBqbaUjqhsgD0IPBS5+NrsslcO3uH/jkP 6oN44B3B3QuhWXRTsBRWrGihLV611VfQv4yppllGKLlBSTrkrzGMobUHDRO7it8OTIxz WseSK+ZgjtH/tPxR3U6eC8j3mC0qkNwEdaXMM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=BxStKevL7hpzAZ8y3mGCwS6nRTJigfGkAGanJC0woWGRmTguHx2PfxEvTgYONNhB/a I81XlgDhyApU14tz8UgVYtxjYZ+huFqoNEW+0wE8stqs8xJCywNmgMpr1zckitkDqvLi U1QodxwOsnHKnwGuxG4lxuuofLiYQGpkoql5A= MIME-Version: 1.0 Received: by 10.102.171.37 with SMTP id t37mr5466901mue.92.1264694786633; Thu, 28 Jan 2010 08:06:26 -0800 (PST) Date: Thu, 28 Jan 2010 19:06:26 +0300 Message-ID: <7c263eca1001280806x6e07ccc7xe4ef49aa566aa926@mail.gmail.com> From: Vladimir Osipenko To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Packets disappear after ngtee rule 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, 28 Jan 2010 16:32:54 -0000 Good day! I have a FreeBSD shaping bridge based on lagg+dummynet, this is a part from ruleset: 03001 20 7840 ngtee 10 ip from any to any out xmit lagg1 03003 0 0 allow log ip from any to any So, the problem is that packets after passing rule with ngtee disappear (droped?) and are not returned back to the next rule. net.inet.ip.fw.one_pass: 0 So, as I understand, ng_ipfw must return packets back, but it does not. Can someone give me a hint where to look or what to check more? From owner-freebsd-net@FreeBSD.ORG Thu Jan 28 17:05:37 2010 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 1CEBB1065672 for ; Thu, 28 Jan 2010 17:05:37 +0000 (UTC) (envelope-from brett@lariat.net) Received: from lariat.net (lariat.net [66.119.58.2]) by mx1.freebsd.org (Postfix) with ESMTP id 952ED8FC08 for ; Thu, 28 Jan 2010 17:05:36 +0000 (UTC) Received: from anne-o1dpaayth1.lariat.net (IDENT:ppp1000.lariat.net@lariat.net [66.119.58.2]) by lariat.net (8.9.3/8.9.3) with ESMTP id KAA27713; Thu, 28 Jan 2010 10:04:53 -0700 (MST) Message-Id: <201001281704.KAA27713@lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 28 Jan 2010 09:57:16 -0700 To: Bruce Simpson From: Brett Glass In-Reply-To: <4B6129E5.50009@incunabulum.net> References: <201001280126.SAA18331@lariat.net> <4B6129E5.50009@incunabulum.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: Ralink 28xx series drivers? 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, 28 Jan 2010 17:05:37 -0000 Thank you! The adapter which I am trying to get running is mini-PCI, not USB. If there's code available, I'd be glad to test it. --Brett Glass At 11:08 PM 1/27/2010, Bruce Simpson wrote: >On 01/28/10 01:26, Brett Glass wrote: >>I am trying to make FreeBSD 8.0 fully functional on an ASUS mini-workstation >>that seems to have a Ralink RT2860 card inside. The "ral" driver for FreeBSD >>doesn't recognize the card. >> >>Apparently, OpenBSD does have a driver for this chip. Is anyone porting it? >>Please copy me on responses, as I am not a full time subscriber of this list. >> > >I can successfully get an RT3071 based Sitecom WL-344 dongle to >attach and associate. HostAP mode may take more work. From owner-freebsd-net@FreeBSD.ORG Thu Jan 28 17:48:47 2010 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 54638106566B for ; Thu, 28 Jan 2010 17:48:47 +0000 (UTC) (envelope-from aaldrich@ihouseweb.com) Received: from mail01.cisdata.net (mail01.cisdata.net [63.82.223.112]) by mx1.freebsd.org (Postfix) with ESMTP id 386C18FC12 for ; Thu, 28 Jan 2010 17:48:47 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=cisdata200707; d=ihouseweb.com; h=Received:Subject:Reply-To:From:Content-Type:Message-Id:Date:To:Content-Transfer-Encoding:Mime-Version:X-Mailer:DomainKey-Status:X-Original-Rcpt; b=fYxxSAExZ6h9BbDSVxHgpOqwzuPrqhwSvqM4uWpID/nveBU/kDHsS7hU2qygqf/RzI2re/RxB3hSKvgJcJZLWVGzLUkovTj3qwi+Uaui44hidb/892Y3ikiU5xInAG0d; Received: from balance02.internal.cisdata.net ([192.168.44.208] helo=[192.168.45.138]) by mail01.cisdata.net with esmtp (Exim 4.69) (envelope-from ) id 1NaXVq-0002vH-O5 for freebsd-net@freebsd.org; Thu, 28 Jan 2010 08:46:34 -0800 From: Alan Aldrich Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Message-Id: Date: Thu, 28 Jan 2010 08:46:33 -0800 To: freebsd-net@freebsd.org Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v1075.2) X-Mailer: Apple Mail (2.1075.2) DomainKey-Status: no signature X-Original-Rcpt: freebsd-net@freebsd.org Subject: NFS mount properties X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alan Aldrich List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 17:48:47 -0000 I am trying to determine how to examine the actual properties of an nfs mount in FreeBSD In CentOS one can 'cat /proc/mounts' to determine all of the mount properties. Specifically I am trying to confirm whether the mount is using TCP or UDP as I want it to be TCP . Is there some similar way to tell in FreeBSD? My fstab entry says this 192.168.44.55:/mcp/home /net nfs rw,async,-d,-3,-s,-i,noatime,- T 0 0 It mounts fine, but I want to confirm that it is actually mounting with TCP and not UDP and cannot figure out what tool will tell me this. 'mount' tells me this 192.168.44.55:/mcp/home on /net (nfs, asynchronous, noatime) but not whether it is mounted TCP or UDP Any help appreciated. Thanks Alan Aldrich From owner-freebsd-net@FreeBSD.ORG Thu Jan 28 18:29:53 2010 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 80D78106568D for ; Thu, 28 Jan 2010 18:29:53 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id 5036E8FC14 for ; Thu, 28 Jan 2010 18:29:53 +0000 (UTC) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id o0SITq2g026905; Thu, 28 Jan 2010 10:29:52 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Thu, 28 Jan 2010 10:29:47 -0800 Message-ID: In-Reply-To: <6dd1343e1001280356u77e4d1f3wfe668da2970e62e7@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ECMP support in FreeBSD 7.2 and 8.0 + Thread-Index: AcqgFN3k6m5fAMHeSOezelguGadOeAAMlXNA References: <6dd1343e1001280356u77e4d1f3wfe668da2970e62e7@mail.gmail.com> From: "Li, Qing" To: "Balaji G" , Cc: Subject: RE: ECMP support in FreeBSD 7.2 and 8.0 + 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, 28 Jan 2010 18:29:53 -0000 RUNNUCBzdXBwb3J0IGlzIG9ubHkgYXZhaWxhYmxlIGluIEZyZWVCU0QgOC4wLg0KDQpJIGhhdmUg bm90IHJlY2VpdmVkIGFueSByZXF1ZXN0IHRvIG1lcmdlIHRoYXQgZmVhdHVyZSBiYWNrIA0KaW50 byA3LnggYnJhbmNoLg0KDQpJbiBGcmVlQlNEIDguMCwgY3VycmVudGx5IHRoZXJlIGlzIG5vIGFz c29jaWF0aW9uIGJldHdlZW4gaW50ZXJmYWNlIA0KbGluayBzdGF0ZSBhbmQgdGhlIHJvdXRlIGF2 YWlsYWJpbGl0eSBSVEZfVVAgZmxhZywgc28gRUNNUCBjYW5ub3QNCmJlIHVzZWQgYXMgYSBmYWls b3ZlciBtZWNoYW5pc20gZWZmZWN0aXZlbHkuDQoNCkkgaGF2ZSBhIHdvcmtpbmcgcGF0Y2ggdG8g YWRkcmVzcyB0aGF0IGRlZmljaWVuY3kgYW5kIHdpbGwgY29tbWl0DQp0aGUgcGF0Y2ggb25jZSBJ IGZpbmQgbW9yZSB0aW1lIHRvIGRvIGFkZGl0aW9uYWwgdW5pdCB0ZXN0aW5nIG9uIGl0Lg0KDQot LVFpbmcNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IG93bmVyLWZy ZWVic2QtbmV0QGZyZWVic2Qub3JnIFttYWlsdG86b3duZXItZnJlZWJzZC0NCj4gbmV0QGZyZWVi c2Qub3JnXSBPbiBCZWhhbGYgT2YgQmFsYWppIEcNCj4gU2VudDogVGh1cnNkYXksIEphbnVhcnkg MjgsIDIwMTAgMzo1NiBBTQ0KPiBUbzogZnJlZWJzZC1uZXRAZnJlZWJzZC5vcmcNCj4gU3ViamVj dDogRUNNUCBzdXBwb3J0IGluIEZyZWVCU0QgNy4yIGFuZCA4LjAgKw0KPiANCj4gSGkgRXZlcnli b2R5DQo+IA0KPiBJIHdvdWxkIGxpa2UgdG8ga25vdyB3aGV0aGVyIEVDTVAgZmVhdHVyZSBpcyBz dXBwb3J0ZWQgaW4gRnJlZUJTRCA3LjIuDQo+IEkgd2FzIGFibGUgdG8gaW5mZXIgdGhhdCBFQ01Q IGlzIHN1cHBvcnRlZCBpbiBGcmVlQlNEIDguMCBiZWNhdXNlIGkNCj4gd2FzIGFibGUgdG8gbG9v ayBpbnRvIHRoZSBTVk4gY2hlY2tpbiBsb2dzIGFuZCBhbHNvIGZvdW5kIG91dCB0aGF0IGluDQo+ IEZyZWVCU0QgOC4wIHRoZSBFQ01QIGNvZGUgd2FzIHdyYXBwZWQgdW5kZXIgUkFESVhfTVBBVEgg bWFjcm8uDQo+IA0KPiBJIHdhcyBub3QgYWJsZSB0byBnZXQgYW55IHJlc3VsdHMgd2hlbiBpIGRp ZCBhIHNlYXJjaCBmb3IgUkFESVhfTVBBVEgNCj4gaW4gNy4yLiBJIHdvdWxkIGxpa2UgdG8ga25v dyB3aGV0aGVyIEVDTVAgY29kZSBleGlzdHMgaW4gNy4yIGFuZA0KPiB3aGV0aGVyIGl0IHByb3Zp ZGVzIHRoZSBzYW1lIGZ1bmN0aW9uYWxpdHkgYXMgZ2l2ZW4gaW4gRnJlZUJTRCA4LjANCj4gDQo+ IFRoYW5rcyBmb3IgeW91ciB0aW1lLg0KPiANCj4gQ2hlZXJzLA0KPiAgIC0gQmFsYWppDQo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGZyZWVic2Qt bmV0QGZyZWVic2Qub3JnIG1haWxpbmcgbGlzdA0KPiBodHRwOi8vbGlzdHMuZnJlZWJzZC5vcmcv bWFpbG1hbi9saXN0aW5mby9mcmVlYnNkLW5ldA0KPiBUbyB1bnN1YnNjcmliZSwgc2VuZCBhbnkg bWFpbCB0byAiZnJlZWJzZC1uZXQtdW5zdWJzY3JpYmVAZnJlZWJzZC5vcmciDQo= From owner-freebsd-net@FreeBSD.ORG Thu Jan 28 23:08:59 2010 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 6A522106568D for ; Thu, 28 Jan 2010 23:08:59 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id E5E798FC1A for ; Thu, 28 Jan 2010 23:08:58 +0000 (UTC) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id o0SMUcqW071414 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 28 Jan 2010 23:30:38 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by cicely5.cicely.de (8.14.2/8.14.2) with ESMTP id o0SMUWEx052517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Jan 2010 23:30:32 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id o0SMUVH1007012; Thu, 28 Jan 2010 23:30:31 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id o0SMUVDK007011; Thu, 28 Jan 2010 23:30:31 +0100 (CET) (envelope-from ticso) Date: Thu, 28 Jan 2010 23:30:31 +0100 From: Bernd Walter To: Alexander Motin Message-ID: <20100128223031.GH4301@cicely7.cicely.de> References: <1246202598.00132971.1246192201@10.7.7.3> <4A4797F9.9040509@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A4797F9.9040509@FreeBSD.org> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, BAYES_00=-2.599 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on spamd.cicely.de Cc: freebsd-net , Bruce Simpson Subject: Re: Anyone working on RNDIS support? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 23:08:59 -0000 On Sun, Jun 28, 2009 at 07:19:05PM +0300, Alexander Motin wrote: > Bruce Simpson wrote: > >Is anyone out there working on RNDIS driver support for FreeBSD? > > > >Just interested if anyone is doing it; the only RNDIS device I have is > >my cable modem (which already has an Ethernet port), however, we are > >seeing more Wi-Fi and DSL devices with USB RNDIS, and it would be great > >to have this support. > > RNDIS is also used by Windows Mobile PDAs for USB connectivity. If > somebody wants to work on this, I am ready do be an alpha-tester. > Existing BT PAN interface I am using now is cool, but not very > power-effective. Is there anything new about this topic? I just tried out contiki on AVR raven devkit. I was surprised when I noticed that the documentation said nothing special about running on Linux and my first thought was CDC ethernet. Now I know they implemented RNDIS support. The nice thing about it is that this USB device has open source. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-net@FreeBSD.ORG Fri Jan 29 10:04:40 2010 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 11E41106568B; Fri, 29 Jan 2010 10:04:40 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 40EEC8FC25; Fri, 29 Jan 2010 10:04:39 +0000 (UTC) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id o0TA4bRI099340 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 29 Jan 2010 11:04:37 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by cicely5.cicely.de (8.14.2/8.14.2) with ESMTP id o0TA4Vju079905 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Jan 2010 11:04:31 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id o0TA4VsI010505; Fri, 29 Jan 2010 11:04:31 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id o0TA4VNf010504; Fri, 29 Jan 2010 11:04:31 +0100 (CET) (envelope-from ticso) Date: Fri, 29 Jan 2010 11:04:31 +0100 From: Bernd Walter To: Alexander Motin Message-ID: <20100129100431.GM4301@cicely7.cicely.de> References: <1246202598.00132971.1246192201@10.7.7.3> <4A4797F9.9040509@FreeBSD.org> <20100128223031.GH4301@cicely7.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100128223031.GH4301@cicely7.cicely.de> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, BAYES_00=-2.599 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on spamd.cicely.de Cc: freebsd-net , Bruce Simpson Subject: Re: Anyone working on RNDIS support? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 10:04:40 -0000 On Thu, Jan 28, 2010 at 11:30:31PM +0100, Bernd Walter wrote: > On Sun, Jun 28, 2009 at 07:19:05PM +0300, Alexander Motin wrote: > > Bruce Simpson wrote: > > >Is anyone out there working on RNDIS driver support for FreeBSD? > > > > > >Just interested if anyone is doing it; the only RNDIS device I have is > > >my cable modem (which already has an Ethernet port), however, we are > > >seeing more Wi-Fi and DSL devices with USB RNDIS, and it would be great > > >to have this support. > > > > RNDIS is also used by Windows Mobile PDAs for USB connectivity. If > > somebody wants to work on this, I am ready do be an alpha-tester. > > Existing BT PAN interface I am using now is cool, but not very > > power-effective. > > Is there anything new about this topic? > I just tried out contiki on AVR raven devkit. > I was surprised when I noticed that the documentation said nothing > special about running on Linux and my first thought was CDC ethernet. > Now I know they implemented RNDIS support. > The nice thing about it is that this USB device has open source. In the meantime I've found the following: http://sourceforge.jp/projects/bsd-rndis/ But it is based on old USB stack. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-net@FreeBSD.ORG Fri Jan 29 11:01:04 2010 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 5496C106566B; Fri, 29 Jan 2010 11:01:04 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id 87BAE8FC1F; Fri, 29 Jan 2010 11:01:03 +0000 (UTC) Received: by fxm27 with SMTP id 27so147025fxm.3 for ; Fri, 29 Jan 2010 03:01:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:from:content-type :content-transfer-encoding:subject:date:message-id:to:mime-version :x-mailer; bh=JwWrJBEQHSjE3g4PxphGt4WrEJ3674s8Bi6gVzAs1h4=; b=x9PnFDKxkpjxRW5aMBnS7XGg0u5mRhuygU1GKF6A9xB/jQ/X9CogdiiyvXDTcLVIh5 m6y1KTsNu57kzIRiWSclvmbk1p4ewAAjqwt9sIkSv+xWqESMRU/klu3cavbJ29uO6sX7 b6ZX7btut7UY4kTB4taJTMCRt6IvXubiLuRDo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:from:content-type:content-transfer-encoding:subject:date :message-id:to:mime-version:x-mailer; b=MXyIjYESlqF8UXpf8Lls58MjWArQcEuOCG4wbBJGC5k+y4om6pxTt4sTXFlWh4oYpd hmZxoqvP9K2T4XXvi3U7wmvZ0NEVSTmfYPJPAHFxNIYbjmfQkjCpz0qtGaEJLTjfenmC OGOFCx+QRNFkCxOTh98kKYY4/2Ql6AlbrRbNg= Received: by 10.223.14.216 with SMTP id h24mr450354faa.106.1264762862517; Fri, 29 Jan 2010 03:01:02 -0800 (PST) Received: from ?10.0.10.4? (54.81.54.77.rev.vodafone.pt [77.54.81.54]) by mx.google.com with ESMTPS id 15sm411642fxm.6.2010.01.29.03.01.01 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 29 Jan 2010 03:01:01 -0800 (PST) Sender: Rui Paulo From: Rui Paulo Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 29 Jan 2010 11:00:58 +0000 Message-Id: To: Sergey Vinogradov , Paul Webster , S Smirnov , Eugene Dzhurinsky , freebsd-current@freebsd.org, freebsd-mobile@freebsd.org, freebsd-net@freebsd.org Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Cc: Subject: HEADS UP: Atheros AR9285 support X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 11:01:04 -0000 Hi, I just committed initial support for the Atheros AR9285 wireless chipset = found on many netbooks. The driver still has issues but it's stable = enough for general use (don't expect good throughput, though). I'm looking for testers to make sure I didn't break anything else in the = Atheros driver. If you notice any problems with ath on a recent kernel, please inform = me. Thanks, -- Rui Paulo From owner-freebsd-net@FreeBSD.ORG Fri Jan 29 15:00:19 2010 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 A6D7D1065670 for ; Fri, 29 Jan 2010 15:00:19 +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 94E308FC0A for ; Fri, 29 Jan 2010 15:00:19 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o0TF0Jp8082464 for ; Fri, 29 Jan 2010 15:00:19 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o0TF0JYb082463; Fri, 29 Jan 2010 15:00:19 GMT (envelope-from gnats) Date: Fri, 29 Jan 2010 15:00:19 GMT Message-Id: <201001291500.o0TF0JYb082463@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: "Anishchuk, Igor" Cc: Subject: Re: kern/141646: [em] em(4) + lagg(4) + vlan(4) generates ISL-tagged frames instead of 802.1q-tagged frames X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Anishchuk, Igor" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 15:00:19 -0000 The following reply was made to PR kern/141646; it has been noted by GNATS. From: "Anishchuk, Igor" To: , Cc: Subject: Re: kern/141646: [em] em(4) + lagg(4) + vlan(4) generates ISL-tagged frames instead of 802.1q-tagged frames Date: Fri, 29 Jan 2010 16:39:08 +0200 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAA0F0.D10A7257 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8hDQoNCiANCg0KSSBoYXZlIHRoZSBzYW1lIGlzc3VlLCBidXQgSSBzdXNwZWN0IGl0IGlz IG5vdCBJU0wtdGFnZ2VkIHBhY2tldHMsIGJ1dA0KdHdpY2UtdGFnZ2VkIDgwMi4xcSBwYWNrZXRz LiBUaGVyZSBpcyBhIHdvcmthcm91bmQgZm9yIHRoZSBwcm9ibGVtOg0KDQogDQoNCmlmY29uZmln X2VtMD0iLXZsYW5od3RhZyB1cCINCg0KaWZjb25maWdfZW0xPSItdmxhbmh3dGFnIHVwIg0KDQpp ZmNvbmZpZ19lbTI9Ii12bGFuaHd0YWcgdXAiDQoNCmlmY29uZmlnX2VtMz0iLXZsYW5od3RhZyB1 cCINCg0KY2xvbmVkX2ludGVyZmFjZXM9ImxhZ2cwIHZsYW4xMCINCg0KaWZjb25maWdfbGFnZzA9 ImxhZ2dwcm90byBmZWMgbGFnZ3BvcnQgZW0wIGxhZ2dwb3J0IGVtMSBsYWdncG9ydCBlbTIgbGFn Z3BvcnQNCmVtMyB1cCINCg0KaWZjb25maWdfdmxhbjEwPSJ2bGFuIDEwIHZsYW5kZXYgbGFnZzAg MTkyLjE2OC4xMC4yLzI0Ig0KDQogDQoNClJlZ2FyZHMsDQoNCiANCg0KIA0KDQpJZ29yIEFuaXNo Y2h1aw0KU2VuaW9yIFN5c3RlbXMgQXJjaGl0ZWN0LCBQcm9kdWN0aW9uIGFuZCBTaXRlcw0KDQpG LVNlY3VyZSBDb3Jwb3JhdGlvbg0KTW9iaWxlICszNTggNDAgODM5IDM2MjANCg0KUHJvdGVjdGlu ZyB0aGUgaXJyZXBsYWNlYWJsZSBJIHd3dy5mLXNlY3VyZS5jb20gPGh0dHA6Ly93d3cuZi1zZWN1 cmUuY29tLz4gDQoNCiANCg0K ------_=_NextPart_001_01CAA0F0.D10A7257 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2 YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpydGM9 Imh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9IkRB VjoiIHhtbG5zOlJlcGw9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5z Om10PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9tZWV0aW5n cy8iIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNlbC8y MDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0cDovL3d3dy5wYXNzcG9ydC5jb20vTmFtZVNwYWNlLnhz ZCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3ht bGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYyIg eG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRz LyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jIyIgeG1sbnM6c3A9 Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcz0iaHR0 cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvIiB4bWxuczp4c2k9Imh0 dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp1ZGNzPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5zOnVkY3hmPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZpbGUiIHhtbG5zOnVkY3AycD0i aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3 Zj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cv IiB4bWxuczpkc3NzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2Rp Z3NpZy1zZXR1cCIgeG1sbnM6ZHNzaT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp Y2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0 cy5vcmcvcGFja2FnZS8yMDA2L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyPSJodHRwOi8v c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvbWFya3VwLWNvbXBhdGliaWxpdHkvMjAwNiIgeG1s bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4 bWxuczptcmVscz0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAw Ni9yZWxhdGlvbnNoaXBzIiB4bWxuczpzcHdwPSJodHRwOi8vbWljcm9zb2Z0LmNvbS9zaGFyZXBv aW50L3dlYnBhcnRwYWdlcyIgeG1sbnM6ZXgxMnQ9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBlcyIgeG1sbnM6ZXgxMm09Imh0dHA6Ly9zY2hl bWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1sbnM6 cHB0c2w9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaWRl TGlicmFyeS8iIHhtbG5zOnNwc2w9Imh0dHA6Ly9taWNyb3NvZnQuY29tL3dlYnNlcnZpY2VzL1No YXJlUG9pbnRQb3J0YWxTZXJ2ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpaPSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6c3Q9IiYjMTsiIHhtbG5zPSJodHRwOi8vd3d3 LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PUNvbnRl bnQtVHlwZSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT1H ZW5lcmF0b3IgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0K PHN0eWxlPg0KPCEtLQ0KIC8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCiBAZm9udC1mYWNlDQoJe2Zv bnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAy IDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9z ZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkFy aWFsIEJvbGQiO30NCiAvKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KIHAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0 ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNldGF0 ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJU YWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUt bmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1z ZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0K QHBhZ2UgU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjIuMGNtIDQy LjVwdCAyLjBjbSAzLjBjbTt9DQpkaXYuU2VjdGlvbjENCgl7cGFnZTpTZWN0aW9uMTt9DQotLT4N Cjwvc3R5bGU+DQo8IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQogPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KICA8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCiA8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQoNCjxib2R5IGxhbmc9RU4tVVMgbGluaz1ibHVlIHZsaW5rPXB1cnBs ZT4NCg0KPGRpdiBjbGFzcz1TZWN0aW9uMT4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPkhlbGxvITxv OnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+ DQoNCjxwIGNsYXNzPU1zb05vcm1hbD5JIGhhdmUgdGhlIHNhbWUgaXNzdWUsIGJ1dCBJIHN1c3Bl Y3QgaXQgaXMgbm90IElTTC10YWdnZWQNCnBhY2tldHMsIGJ1dCB0d2ljZS10YWdnZWQgODAyLjFx IHBhY2tldHMuIFRoZXJlIGlzIGEgd29ya2Fyb3VuZCBmb3IgdGhlDQpwcm9ibGVtOjxvOnA+PC9v OnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+DQoNCjxw IGNsYXNzPU1zb05vcm1hbD5pZmNvbmZpZ19lbTA9JnF1b3Q7LXZsYW5od3RhZyB1cCZxdW90Ozxv OnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+aWZjb25maWdfZW0xPSZxdW90Oy12 bGFuaHd0YWcgdXAmcXVvdDs8bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPmlm Y29uZmlnX2VtMj0mcXVvdDstdmxhbmh3dGFnIHVwJnF1b3Q7PG86cD48L286cD48L3A+DQoNCjxw IGNsYXNzPU1zb05vcm1hbD5pZmNvbmZpZ19lbTM9JnF1b3Q7LXZsYW5od3RhZyB1cCZxdW90Ozxv OnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+Y2xvbmVkX2ludGVyZmFjZXM9JnF1 b3Q7bGFnZzAgdmxhbjEwJnF1b3Q7PG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1h bD5pZmNvbmZpZ19sYWdnMD0mcXVvdDtsYWdncHJvdG8gZmVjIGxhZ2dwb3J0IGVtMCBsYWdncG9y dCBlbTENCmxhZ2dwb3J0IGVtMiBsYWdncG9ydCBlbTMgdXAmcXVvdDs8bzpwPjwvbzpwPjwvcD4N Cg0KPHAgY2xhc3M9TXNvTm9ybWFsPmlmY29uZmlnX3ZsYW4xMD0mcXVvdDt2bGFuIDEwIHZsYW5k ZXYgbGFnZzANCjE5Mi4xNjguMTAuMi8yNCZxdW90OzxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFz cz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD5S ZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8 L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCg0K PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6IkFyaWFsIEJvbGQiOw0KY29sb3I6IzYyNjk3MSc+SWdvciBBbmlzaGNodWs8YnI+DQo8L3Nw YW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5z LXNlcmlmIjsNCmNvbG9yOiM2MjY5NzEnPlNlbmlvciBTeXN0ZW1zIEFyY2hpdGVjdCwgUHJvZHVj dGlvbiBhbmQgU2l0ZXM8YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiM2MDY3NkYnPjxicj4NCjwv c3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNh bnMtc2VyaWYiOw0KY29sb3I6IzYyNjk3MSc+Ri1TZWN1cmUgQ29ycG9yYXRpb248YnI+DQpNb2Jp bGUgKzM1OCA0MCA4MzkgMzYyMDxicj4NCjxicj4NClByb3RlY3RpbmcgdGhlIGlycmVwbGFjZWFi bGUgSSA8YSBocmVmPSJodHRwOi8vd3d3LmYtc2VjdXJlLmNvbS8iPjxzcGFuDQpzdHlsZT0nY29s b3I6Ymx1ZSc+d3d3LmYtc2VjdXJlLmNvbTwvc3Bhbj48L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+DQoNCjwvZGl2Pg0K DQo8L2JvZHk+DQoNCjwvaHRtbD4NCg== ------_=_NextPart_001_01CAA0F0.D10A7257-- From owner-freebsd-net@FreeBSD.ORG Fri Jan 29 15:40:08 2010 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 1E5CA106566C for ; Fri, 29 Jan 2010 15:40:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id 9B4918FC12 for ; Fri, 29 Jan 2010 15:40:07 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 9C97041C7CF for ; Fri, 29 Jan 2010 16:40:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id 72Iv+03fPBYN for ; Fri, 29 Jan 2010 16:40:06 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id EDF8D41C7CC; Fri, 29 Jan 2010 16:40:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id B8C7C4448EC for ; Fri, 29 Jan 2010 15:37:43 +0000 (UTC) Date: Fri, 29 Jan 2010 15:37:43 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: freebsd-net@freebsd.org In-Reply-To: <20100123104843.G50938@maildrop.int.zabbadoz.net> Message-ID: <20100129153533.Q50938@maildrop.int.zabbadoz.net> References: <20100123104843.G50938@maildrop.int.zabbadoz.net> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: NAT-T patch from stable/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: Fri, 29 Jan 2010 15:40:08 -0000 On Sat, 23 Jan 2010, Bjoern A. Zeeb wrote: Hi, there is an updated version. I wonder why it was missed - probably because noone was complaining loud enough or I missed it or noone had seen it or ... and I am not running 7.x anymore myself but HEAD;) -- all my former stable/7 patches had missed one fixed that this one now includes. Enjoy. > with an upcoming 7.3-RELEASE I have put an updated (though not tested;-) > NAT-T patch from stable/7 at http://people.freebsd.org/~bz/20100129-01-ipsec-natt-mfc7.diff > Please read this _entire_ thread (and possible later follow-ups) about > how to use it: > http://lists.freebsd.org/pipermail/freebsd-net/2009-August/thread.html#22722 /bz -- Bjoern A. Zeeb It will not break if you know what you are doing. From owner-freebsd-net@FreeBSD.ORG Fri Jan 29 15:56:19 2010 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 A44311065676; Fri, 29 Jan 2010 15:56:19 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id B2D868FC16; Fri, 29 Jan 2010 15:56:18 +0000 (UTC) Received: by fxm27 with SMTP id 27so435576fxm.3 for ; Fri, 29 Jan 2010 07:56:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=M05tgLi8XhFz4cFCUtV8dLbiU8+NSDOBztgiZ/Ct+x4=; b=kyRTiWXZXzoUD2nC2uQjx032kaGCOpHtSE4w17ZfzYIU/5M8DdP1KO6qldRHCpCvAN cxPZW2tPFm5F/L4cUxIBkNFWGPBZSsSUzTBEJ/qsGefrNXw3gC0zPZOrz9M1a/0MP3H8 /k+JfL+JrUC38Ugw0znyxV+4Re4ZdtRAVzJbE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=m6qHJcLSL0A+lWQmID9rb2z5YFj19cL2xZBZkSmEu9j2m0IB6nSK9rqhtMh381FSYk iaaKjtjpFZWMo42wGlczxbch9Z0iD4pE9z8VTvvPm3tR4F4NjXG9am016KKDYh6mhJKq M/ODtJuH75nZQZ86dUoQSMDVuCtwrGhlrNXj8= Received: by 10.223.29.193 with SMTP id r1mr938011fac.29.1264780577600; Fri, 29 Jan 2010 07:56:17 -0800 (PST) Received: from ?10.0.10.4? (54.81.54.77.rev.vodafone.pt [77.54.81.54]) by mx.google.com with ESMTPS id 15sm548020fxm.2.2010.01.29.07.56.15 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 29 Jan 2010 07:56:16 -0800 (PST) Sender: Rui Paulo Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Rui Paulo In-Reply-To: Date: Fri, 29 Jan 2010 15:56:14 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <37797801-B178-485B-A5E1-CA42CA0619DB@freebsd.org> References: To: Rui Paulo X-Mailer: Apple Mail (2.1077) Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, freebsd-mobile@freebsd.org Subject: Re: HEADS UP: Atheros AR9285 support X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 15:56:19 -0000 On 29 Jan 2010, at 11:00, Rui Paulo wrote: > Hi, > I just committed initial support for the Atheros AR9285 wireless = chipset found on many netbooks. The driver still has issues but it's = stable enough for general use (don't expect good throughput, though). >=20 > I'm looking for testers to make sure I didn't break anything else in = the Atheros driver. > If you notice any problems with ath on a recent kernel, please inform = me. Patch against stable/8: http://people.freebsd.org/~rpaulo/ar9285_stable_8.diff -- Rui Paulo From owner-freebsd-net@FreeBSD.ORG Fri Jan 29 18:20:12 2010 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 0ED8F106568F for ; Fri, 29 Jan 2010 18:20: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 F2B568FC1D for ; Fri, 29 Jan 2010 18:20:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o0TIKBfa054164 for ; Fri, 29 Jan 2010 18:20:11 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o0TIKBGs054163; Fri, 29 Jan 2010 18:20:11 GMT (envelope-from gnats) Date: Fri, 29 Jan 2010 18:20:11 GMT Message-Id: <201001291820.o0TIKBGs054163@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/143163: 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: Fri, 29 Jan 2010 18:20:12 -0000 The following reply was made to PR kern/143163; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/143163: commit references a PR Date: Fri, 29 Jan 2010 18:18:37 +0000 (UTC) Author: rpaulo Date: Fri Jan 29 18:18:18 2010 New Revision: 203172 URL: http://svn.freebsd.org/changeset/base/203172 Log: MFC r202967: Call ieee80211_radiotap_rx, not ieee80211_radiotap_tx on sta_input() PR: 143163 Submitted by:Alexander Egorenkov Modified: stable/8/sys/net80211/ieee80211_sta.c Directory Properties: stable/8/sys/ (props changed) stable/8/sys/amd64/include/xen/ (props changed) stable/8/sys/cddl/contrib/opensolaris/ (props changed) stable/8/sys/contrib/dev/acpica/ (props changed) stable/8/sys/contrib/pf/ (props changed) stable/8/sys/dev/xen/xenpci/ (props changed) Modified: stable/8/sys/net80211/ieee80211_sta.c ============================================================================== --- stable/8/sys/net80211/ieee80211_sta.c Fri Jan 29 16:14:35 2010 (r203171) +++ stable/8/sys/net80211/ieee80211_sta.c Fri Jan 29 18:18:18 2010 (r203172) @@ -759,7 +759,7 @@ sta_input(struct ieee80211_node *ni, str /* copy to listener after decrypt */ if (ieee80211_radiotap_active_vap(vap)) - ieee80211_radiotap_tx(vap, m); + ieee80211_radiotap_rx(vap, m); need_tap = 0; /* _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Fri Jan 29 19:20:10 2010 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 883BA106566B for ; Fri, 29 Jan 2010 19:20:10 +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 763C88FC08 for ; Fri, 29 Jan 2010 19:20:10 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o0TJKAFr005499 for ; Fri, 29 Jan 2010 19:20:10 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o0TJKAw9005498; Fri, 29 Jan 2010 19:20:10 GMT (envelope-from gnats) Date: Fri, 29 Jan 2010 19:20:10 GMT Message-Id: <201001291920.o0TJKAw9005498@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: "Anishchuk, Igor" Cc: Subject: Re: kern/141646: [em] em(4) + lagg(4) + vlan(4) generates ISL-tagged frames instead of 802.1q-tagged frames X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Anishchuk, Igor" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 19:20:10 -0000 The following reply was made to PR kern/141646; it has been noted by GNATS. From: "Anishchuk, Igor" To: , Cc: Subject: Re: kern/141646: [em] em(4) + lagg(4) + vlan(4) generates ISL-tagged frames instead of 802.1q-tagged frames Date: Fri, 29 Jan 2010 21:16:57 +0200 SGVsbG8hDQoNCk15IGFwb2xvZ2llcyBmb3IgdGhlIHByZXZpb3VzIG1lc3NhZ2UuDQoNCkkgaGF2 ZSB0aGUgc2FtZSBpc3N1ZSwgYnV0IEkgc3VzcGVjdCBpdCBpcyBub3QgSVNMLXRhZ2dlZCBwYWNr ZXRzLCBidXQNCnR3aWNlLXRhZ2dlZCA4MDIuMXEgcGFja2V0cy4gVGhlcmUgaXMgYSB3b3JrYXJv dW5kIGZvciB0aGUgcHJvYmxlbToNCg0KaWZjb25maWdfZW0wPSItdmxhbmh3dGFnIHVwIg0KaWZj b25maWdfZW0xPSItdmxhbmh3dGFnIHVwIg0KaWZjb25maWdfZW0yPSItdmxhbmh3dGFnIHVwIg0K aWZjb25maWdfZW0zPSItdmxhbmh3dGFnIHVwIg0KY2xvbmVkX2ludGVyZmFjZXM9ImxhZ2cwIHZs YW4xMCINCmlmY29uZmlnX2xhZ2cwPSJsYWdncHJvdG8gZmVjIGxhZ2dwb3J0IGVtMCBsYWdncG9y dCBlbTEgbGFnZ3BvcnQgZW0yIGxhZ2dwb3J0DQplbTMgdXAiDQppZmNvbmZpZ192bGFuMTA9InZs YW4gMTAgdmxhbmRldiBsYWdnMCAxOTIuMTY4LjEwLjIvMjQiDQoNClJlZ2FyZHMsDQoNCg0KSWdv ciBBbmlzaGNodWsNClNlbmlvciBTeXN0ZW1zIEFyY2hpdGVjdCwgUHJvZHVjdGlvbiBhbmQgU2l0 ZXMNCg0KRi1TZWN1cmUgQ29ycG9yYXRpb24NCk1vYmlsZSArMzU4IDQwIDgzOSAzNjIwDQoNClBy b3RlY3RpbmcgdGhlIGlycmVwbGFjZWFibGUgSSB3d3cuZi1zZWN1cmUuY29tDQoNCg== From owner-freebsd-net@FreeBSD.ORG Fri Jan 29 22:02:18 2010 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 61DE81065693 for ; Fri, 29 Jan 2010 22:02:18 +0000 (UTC) (envelope-from kenneth@ubh.homeip.net) Received: from smtp.bredband2.com (smtp.bredband2.com [83.219.192.166]) by mx1.freebsd.org (Postfix) with ESMTP id D3B488FC1A for ; Fri, 29 Jan 2010 22:02:17 +0000 (UTC) Received: from ubh.homeip.net (c-83-233-35-119.cust.bredband2.com [83.233.35.119]) (Authenticated sender: ed5470) by smtp.bredband2.com (Postfix) with ESMTPA id C344B6CC22 for ; Fri, 29 Jan 2010 22:46:25 +0100 (CET) Received: from ASSP.nospam (localhost [127.0.0.1]) by ubh.homeip.net (Postfix) with SMTP id 2B0C72842D for ; Fri, 29 Jan 2010 22:46:25 +0100 (CET) Received: from kennethPC ([192.168.1.250] helo=kennethPC) with IPv4:25 by ASSP.nospam; 29 Jan 2010 22:46:25 +0100 Message-ID: From: "Kenneth Hilmersson" To: Date: Fri, 29 Jan 2010 22:46:26 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 X-Bredband2-MailScanner: Found to be clean X-Bredband2-MailScanner-From: kenneth@ubh.homeip.net X-Spam-Status: No Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Strange network issue in freebsd 8 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, 29 Jan 2010 22:02:18 -0000 > The servers loses network connection once in a few days. I logged into > console and verified that network is up. I even restarted network = service > using following command. > > /etc/rc.d/netif restart > > Still, it didn't fix. > > I checked /var/log/messages, but I am not getting any clue. I see exactly the same thing. My network dies after a couple of days in = the same manner. My friend have problems with different network cards in 8.0: em, msk, age locks up and with sis the network performance drops to = 0.1kbps after awhile. BR Kenneth From owner-freebsd-net@FreeBSD.ORG Fri Jan 29 22:47:41 2010 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 8CF661065670 for ; Fri, 29 Jan 2010 22:47:41 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ew0-f217.google.com (mail-ew0-f217.google.com [209.85.219.217]) by mx1.freebsd.org (Postfix) with ESMTP id 2130B8FC16 for ; Fri, 29 Jan 2010 22:47:40 +0000 (UTC) Received: by ewy9 with SMTP id 9so190839ewy.3 for ; Fri, 29 Jan 2010 14:47:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=qpBGlLGdFCwV1YnUETme9TfCu6SLVOJPWUbEk/5ipPM=; b=oqTaSUdpPPHBPIkVbkc/0a1/tnrEKRg+OReyOquwZx6XI2GUbnftI0JRudCSZb1nom ocamutj3TMv/1+m/EdvvcKx3FVcDrYlMtg4Qk13ybOeRzB3mS/RFE1y3zBoHEsIrXphg V08k0BcZX9rp+joOVhxW61JYpnF+p4z6T1gHw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=RaTgwTZKwHlDx9b/MDldyCaIaxdy8dqaysUfpa1s8T+7vIpOhl8sMLl9xgXu/KZOr8 wJ5ddWb81U21p1gKeKtP+6UhqPxM/tNzOiK986S0qqBf0gM1ipXqoy6Fik7rxRtbPGK7 7WqzRrgWoH9YxHnvxs+t6fa3AoX4WJD8cLxik= MIME-Version: 1.0 Received: by 10.216.87.79 with SMTP id x57mr890372wee.83.1264805259816; Fri, 29 Jan 2010 14:47:39 -0800 (PST) In-Reply-To: <201001291920.o0TJKAw9005498@freefall.freebsd.org> References: <201001291920.o0TJKAw9005498@freefall.freebsd.org> Date: Fri, 29 Jan 2010 14:47:39 -0800 Message-ID: <2a41acea1001291447n5852f5b4h193d3ad6dff9faac@mail.gmail.com> From: Jack Vogel To: FreeBSD Net , Jeff Blank Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: kern/141646: [em] em(4) + lagg(4) + vlan(4) generates ISL-tagged frames instead of 802.1q-tagged frames 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, 29 Jan 2010 22:47:41 -0000 What's with the encrypted messages entered in this bug suddenly? An important update - I have root caused this. Turns out its kinda interesting. The reason there is a problem is due to the stacked pseudo devices, since the vlan device is on lagg, and not directly on em, the em driver is not getting the "event" of the vlan attachment, and thus the vlan hw filter routine is never run, that routine sets a CRITICAL bit in the control register which differentiates between ISL and 802 tags... and thus our failure :( The question now is what to do about this, I am thinking about this now.... Jack From owner-freebsd-net@FreeBSD.ORG Fri Jan 29 23:59:13 2010 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 0ACFD1065672 for ; Fri, 29 Jan 2010 23:59:13 +0000 (UTC) (envelope-from jfb@mr-happy.com) Received: from vexbert.mr-paradox.net (vexbert.mr-paradox.net [IPv6:2001:470:b:28:f::1]) by mx1.freebsd.org (Postfix) with ESMTP id DF4688FC15 for ; Fri, 29 Jan 2010 23:59:12 +0000 (UTC) Received: from crow.mr-happy.com (crow.mr-happy.com [10.1.0.2]) by vexbert.mr-paradox.net (Postfix) with ESMTP id 0C076845AE; Fri, 29 Jan 2010 18:59:12 -0500 (EST) Received: by crow.mr-happy.com (Postfix, from userid 16139) id 6D647BAA8; Fri, 29 Jan 2010 18:59:11 -0500 (EST) Date: Fri, 29 Jan 2010 18:59:11 -0500 From: Jeff Blank To: Jack Vogel Message-ID: <20100129235911.GA67110@mr-happy.com> References: <201001291920.o0TJKAw9005498@freefall.freebsd.org> <2a41acea1001291447n5852f5b4h193d3ad6dff9faac@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2a41acea1001291447n5852f5b4h193d3ad6dff9faac@mail.gmail.com> X-Face: #0jV*~a}VtKS-&E/!EJpH('H1Va}24dxF0oT&+.R3Gu8C; xhSC+<|+H84&YLbMvphuRT4cp3.|8EN_(2Eix/6{.Up~u`a^}0Ln&b+9Fw|BPig@-{y\pL_46d&ZwA]5%_AU?}DezfE&1!>H?3E$!Yve7.O<+..Jnb4:'6Ey_]FtFzU9=*l$1p/@gA,Ze>^5<]+r(XJ+m7`/vMDc$'wy|`e X-Virus-Scanned: ClamAV 0.94.2/10342/Fri Jan 29 11:14:10 2010 on vexbert.mr-paradox.net X-Virus-Status: Clean Cc: FreeBSD Net Subject: Re: kern/141646: [em] em(4) + lagg(4) + vlan(4) generates ISL-tagged frames instead of 802.1q-tagged frames 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, 29 Jan 2010 23:59:13 -0000 On Fri, Jan 29, 2010 at 02:47:39PM -0800, Jack Vogel wrote: > What's with the encrypted messages entered in this bug suddenly? Just base64-encoded plain text--it appears GNATS is not base64-aware. To summarize (I received a copy directly), Mr. Anishchuk is experiencing the same problem and suggested a workaround (also posted to the list previously) involving "ifconfig_emN='-vlanhwtag up'" in rc.conf. He also seemed to think it was twice-Q-tagged frames rather than ISL-tagged frames, which does not match my packet captures. > An important update - I have root caused this. Turns out its kinda > interesting. > The reason there is a problem is due to the stacked pseudo devices, since > the vlan device is on lagg, and not directly on em, the em driver is not > getting > the "event" of the vlan attachment, and thus the vlan hw filter routine is > never > run, that routine sets a CRITICAL bit in the control register which > differentiates > between ISL and 802 tags... and thus our failure :( > The question now is what to do about this, I am thinking about this now.... Interesting indeed. I look forward to a fix (and have alternate interfaces and -vlanhwtag in the mean time). thanks, Jeff From owner-freebsd-net@FreeBSD.ORG Sat Jan 30 00:13:52 2010 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 4FF03106568B for ; Sat, 30 Jan 2010 00:13:52 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ew0-f211.google.com (mail-ew0-f211.google.com [209.85.219.211]) by mx1.freebsd.org (Postfix) with ESMTP id D67798FC14 for ; Sat, 30 Jan 2010 00:13:51 +0000 (UTC) Received: by ewy3 with SMTP id 3so42984ewy.13 for ; Fri, 29 Jan 2010 16:13:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=cTd8sulznk2769lTT5zNJyOT9SxRR/0dLeYliyL93do=; b=wWlam0sJ5wMr5I9atx+eyNSks1GbrzIuLpMFc6DsMm5pHCkYKyiTIXYE3LBYJJ7ksN PxgYReSq3py6vMTaTDm0xOJVhsaWAFb099xaZTiJedUq7jtpEJAYFYu0rMqXWT3YQOqa zLiUEh/n2lQYLZcetnTqSYAFbnHQpiZo4hbMA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=uZRwwnlLtIzAM7T3v1xYXXZU06Mgj3fW6pE7VIW5wavfF1ldzNqeG8eWESfarGczER OOn/Nt2YJzOkkExk/TH/AyQYSi4NXL5zQYmaIdTk96Xo1mn6f7MMy93p9mfQFHtMyWpX k6MnFzL2+wmxZDItqcWp4/ZNbJr4M9MLRmbtI= MIME-Version: 1.0 Received: by 10.216.178.70 with SMTP id e48mr241025wem.0.1264810430826; Fri, 29 Jan 2010 16:13:50 -0800 (PST) In-Reply-To: <20100129235911.GA67110@mr-happy.com> References: <201001291920.o0TJKAw9005498@freefall.freebsd.org> <2a41acea1001291447n5852f5b4h193d3ad6dff9faac@mail.gmail.com> <20100129235911.GA67110@mr-happy.com> Date: Fri, 29 Jan 2010 16:13:50 -0800 Message-ID: <2a41acea1001291613h41efc00cjd72d4516d9ccec6f@mail.gmail.com> From: Jack Vogel To: Jeff Blank Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD Net Subject: Re: kern/141646: [em] em(4) + lagg(4) + vlan(4) generates ISL-tagged frames instead of 802.1q-tagged frames 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, 30 Jan 2010 00:13:52 -0000 Fix is just checked into HEAD, its sort of a workaround, but really a pretty acceptable one. Let me know if it works for you. Jack On Fri, Jan 29, 2010 at 3:59 PM, Jeff Blank wrote: > On Fri, Jan 29, 2010 at 02:47:39PM -0800, Jack Vogel wrote: > > What's with the encrypted messages entered in this bug suddenly? > > Just base64-encoded plain text--it appears GNATS is not base64-aware. > To summarize (I received a copy directly), Mr. Anishchuk is > experiencing the same problem and suggested a workaround (also posted > to the list previously) involving "ifconfig_emN='-vlanhwtag up'" in > rc.conf. He also seemed to think it was twice-Q-tagged frames rather > than ISL-tagged frames, which does not match my packet captures. > > > An important update - I have root caused this. Turns out its kinda > > interesting. > > The reason there is a problem is due to the stacked pseudo devices, since > > the vlan device is on lagg, and not directly on em, the em driver is not > > getting > > the "event" of the vlan attachment, and thus the vlan hw filter routine > is > > never > > run, that routine sets a CRITICAL bit in the control register which > > differentiates > > between ISL and 802 tags... and thus our failure :( > > The question now is what to do about this, I am thinking about this > now.... > > Interesting indeed. I look forward to a fix (and have alternate > interfaces and -vlanhwtag in the mean time). > > thanks, > Jeff > From owner-freebsd-net@FreeBSD.ORG Sat Jan 30 00:20:59 2010 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 50C321065670 for ; Sat, 30 Jan 2010 00:20:59 +0000 (UTC) (envelope-from jfb@mr-happy.com) Received: from vexbert.mr-paradox.net (vexbert.mr-paradox.net [IPv6:2001:470:b:28:f::1]) by mx1.freebsd.org (Postfix) with ESMTP id 302558FC14 for ; Sat, 30 Jan 2010 00:20:59 +0000 (UTC) Received: from crow.mr-happy.com (crow.mr-happy.com [10.1.0.2]) by vexbert.mr-paradox.net (Postfix) with ESMTP id C0641845AD; Fri, 29 Jan 2010 19:20:58 -0500 (EST) Received: by crow.mr-happy.com (Postfix, from userid 16139) id 8FA8FBAB7; Fri, 29 Jan 2010 19:20:57 -0500 (EST) Date: Fri, 29 Jan 2010 19:20:57 -0500 From: Jeff Blank To: Jack Vogel Message-ID: <20100130002057.GA67562@mr-happy.com> References: <201001291920.o0TJKAw9005498@freefall.freebsd.org> <2a41acea1001291447n5852f5b4h193d3ad6dff9faac@mail.gmail.com> <20100129235911.GA67110@mr-happy.com> <2a41acea1001291613h41efc00cjd72d4516d9ccec6f@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2a41acea1001291613h41efc00cjd72d4516d9ccec6f@mail.gmail.com> X-Face: #0jV*~a}VtKS-&E/!EJpH('H1Va}24dxF0oT&+.R3Gu8C; xhSC+<|+H84&YLbMvphuRT4cp3.|8EN_(2Eix/6{.Up~u`a^}0Ln&b+9Fw|BPig@-{y\pL_46d&ZwA]5%_AU?}DezfE&1!>H?3E$!Yve7.O<+..Jnb4:'6Ey_]FtFzU9=*l$1p/@gA,Ze>^5<]+r(XJ+m7`/vMDc$'wy|`e X-Virus-Scanned: ClamAV 0.94.2/10342/Fri Jan 29 11:14:10 2010 on vexbert.mr-paradox.net X-Virus-Status: Clean Cc: FreeBSD Net Subject: Re: kern/141646: [em] em(4) + lagg(4) + vlan(4) generates ISL-tagged frames instead of 802.1q-tagged frames 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, 30 Jan 2010 00:20:59 -0000 On Fri, Jan 29, 2010 at 04:13:50PM -0800, Jack Vogel wrote: > Fix is just checked into HEAD, its sort of a workaround, but really a > pretty acceptable one. Let me know if it works for you. should it work to import HEAD's sys/dev/e1000 into 8.0R (or some part of it)? I can test it out on Monday if so. anything else I'd need to do in that case? thanks, Jeff From owner-freebsd-net@FreeBSD.ORG Sat Jan 30 00:23:40 2010 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 8E65F106566C for ; Sat, 30 Jan 2010 00:23:40 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ew0-f211.google.com (mail-ew0-f211.google.com [209.85.219.211]) by mx1.freebsd.org (Postfix) with ESMTP id 1F2628FC0A for ; Sat, 30 Jan 2010 00:23:39 +0000 (UTC) Received: by ewy3 with SMTP id 3so49171ewy.13 for ; Fri, 29 Jan 2010 16:23:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=XoFxsVUDGGnkOqIFwuRuxUFhVpxz25YvH9k8v/2Vcd8=; b=U1Rdgc1ZbtGdWKW3DbasJxWw96AEYtNz1HagbfSq1cBXJ2r5FfbQiUczG21/h/DndP l8c6P6WAcZsAgBOfPUPAYoAnEil4buO6REoGZVxuhrrwjNak6gz1TkDe9HivP2J9k6sv tba07omQGluiq5xlhefK2XrjLAkBVr8KV/9KU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=O0Sy3zcqga4VcrBwSn1oKzRVzwTCub1TGTpogZu8QUNzpwjclU1Dltw0k0gqD0mUw3 8I2yRZDqDjaLMCHnn5hIkWJjxPq5D6RjW3fQtkTM6pvrBnnutB3fe7tdPabtZg5V+KK5 Lcy3cc8eH/HML+Po78XoZBvMFAh5Gnr4evRe0= MIME-Version: 1.0 Received: by 10.216.89.205 with SMTP id c55mr138131wef.186.1264811018360; Fri, 29 Jan 2010 16:23:38 -0800 (PST) In-Reply-To: <20100130002057.GA67562@mr-happy.com> References: <201001291920.o0TJKAw9005498@freefall.freebsd.org> <2a41acea1001291447n5852f5b4h193d3ad6dff9faac@mail.gmail.com> <20100129235911.GA67110@mr-happy.com> <2a41acea1001291613h41efc00cjd72d4516d9ccec6f@mail.gmail.com> <20100130002057.GA67562@mr-happy.com> Date: Fri, 29 Jan 2010 16:23:38 -0800 Message-ID: <2a41acea1001291623t6b801f08o6649643772a0afeb@mail.gmail.com> From: Jack Vogel To: Jeff Blank Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD Net Subject: Re: kern/141646: [em] em(4) + lagg(4) + vlan(4) generates ISL-tagged frames instead of 802.1q-tagged frames 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, 30 Jan 2010 00:23:40 -0000 Yes, I believe you can just drop in the directory, BE SURE and save the release code first in case :) Let me know if there are any problems. Cheers, Jack On Fri, Jan 29, 2010 at 4:20 PM, Jeff Blank wrote: > On Fri, Jan 29, 2010 at 04:13:50PM -0800, Jack Vogel wrote: > > Fix is just checked into HEAD, its sort of a workaround, but really a > > pretty acceptable one. Let me know if it works for you. > > should it work to import HEAD's sys/dev/e1000 into 8.0R (or some part > of it)? I can test it out on Monday if so. anything else I'd need to > do in that case? > > thanks, > Jeff > From owner-freebsd-net@FreeBSD.ORG Sat Jan 30 01:58:29 2010 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 CAB47106568F for ; Sat, 30 Jan 2010 01:58:29 +0000 (UTC) (envelope-from prvs=1646183d11=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 5F76C8FC14 for ; Sat, 30 Jan 2010 01:58:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=multiplay.co.uk; s=Multiplay; t=1264816054; x=1265420854; q=dns/txt; h=Received: Message-ID:From:To:Cc:References:Subject:Date:MIME-Version: Content-Type:Content-Transfer-Encoding; bh=lyq2UExwzTK3Hh1D0t0+L 5T25Fcll/zEIpftnvRumm4=; b=TaUoP3gD4LPtppdmlTO1RpnemAz/bfTleu/3Q taHjexjEVM8IGdFXesOe1MKw2sIP/IDH3shODMNPLIAzvvhGfExI/0ZNSJJidUaq v3bwVPFDFT89l/GVs1OtyrNGP3UMv6ldNPoDiR1UgcuFw1kpy9ZEZ0TyF9/UAmdG 4A7754= X-MDAV-Processed: mail1.multiplay.co.uk, Sat, 30 Jan 2010 01:47:34 +0000 Received: from r2d2 by mail1.multiplay.co.uk (MDaemon PRO v10.0.4) with ESMTP id md50009344929.msg for ; Sat, 30 Jan 2010 01:47:34 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Sat, 30 Jan 2010 01:47:34 +0000 (not processed: message from trusted or authenticated source) X-Authenticated-Sender: Killing@multiplay.co.uk X-MDRemoteIP: 213.123.247.160 X-Return-Path: prvs=1646183d11=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-net@freebsd.org Message-ID: <398DD47A113342D78637D600C0C4C47B@multiplay.co.uk> From: "Steven Hartland" To: "Jeff Blank" , "Jack Vogel" References: <201001291920.o0TJKAw9005498@freefall.freebsd.org><2a41acea1001291447n5852f5b4h193d3ad6dff9faac@mail.gmail.com> <20100129235911.GA67110@mr-happy.com> Date: Sat, 30 Jan 2010 01:47:31 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: FreeBSD Net Subject: Re: kern/141646: [em] em(4) + lagg(4) + vlan(4) generatesISL-tagged frames instead of 802.1q-tagged frames 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, 30 Jan 2010 01:58:29 -0000 ----- Original Message ----- From: "Jeff Blank" > Interesting indeed. I look forward to a fix (and have alternate > interfaces and -vlanhwtag in the mean time). Since your using lagg there Jeff have you done on perf testing at all, when I tested here dual em0 + lagg + lacp => cisco 6509 although all seemed to negotiate correctly, balancing wasn't working at all. So I'm wondering if you see the same behaviour or if its just me? Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-net@FreeBSD.ORG Sat Jan 30 04:11:35 2010 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 8BF65106568B for ; Sat, 30 Jan 2010 04:11:35 +0000 (UTC) (envelope-from nazeemnss@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 43C908FC0C for ; Sat, 30 Jan 2010 04:11:35 +0000 (UTC) Received: by vws11 with SMTP id 11so300504vws.13 for ; Fri, 29 Jan 2010 20:11:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=AgE3d8C18MOeChOUTYDi/hqwss5yWMN04RuRHM5h7bU=; b=Ck/8wHr7Esce0xwKT8V5KcytsdBXPq3FvG4pYj/U9VIIS8ZlX+NfMaMNX6kwp06cVi shRwReSm5M/cobVh3Pg8mD4PW256zFOCmRNHR9WLIrQeq/jwZBW0z9PNMBmbthW8qNj3 BPrhKvmsvXmL9m5Pvvm+kYaR3MrBpm2+taJHg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=LZb0m6cbrFzj5ZcCMWKW81NE0RLBpI5NfXBiIvMQjQ1BFXUQSPA9xVLBLrEAQNu0FW NJ1Lv1JiiwQ8XNpyrdn/B7bYuPCwaMqCcBI4UOfC7JkNFYTjoV3Y271GKxxc82fyvFGX m71dsFJNC0IP8w0QSBrygWJLvxPzJPcJfn4Yc= MIME-Version: 1.0 Received: by 10.220.125.17 with SMTP id w17mr1679190vcr.76.1264824694536; Fri, 29 Jan 2010 20:11:34 -0800 (PST) Date: Sat, 30 Jan 2010 09:41:34 +0530 Message-ID: <7609d8391001292011w32ffba13l9e1f94c59ce0d439@mail.gmail.com> From: =?UTF-8?B?TmF6ZWVtINmG2KzZhSDZhNiv2YrZhg==?= To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Tunneling in freeBSD 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, 30 Jan 2010 04:11:35 -0000 hi, Can you suggest way of getting a multicast tunnel work. The assumption is that there is a unicast cloud in between two mbone networks. So we need to forward the multicast traffic over the unicast tunnel. Application is for video transmission. -Nazeem From owner-freebsd-net@FreeBSD.ORG Sat Jan 30 07:10:03 2010 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 8D9AB106568B for ; Sat, 30 Jan 2010 07:10:03 +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 635FD8FC18 for ; Sat, 30 Jan 2010 07:10:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o0U7A3E8028209 for ; Sat, 30 Jan 2010 07:10:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o0U7A3BJ028208; Sat, 30 Jan 2010 07:10:03 GMT (envelope-from gnats) Date: Sat, 30 Jan 2010 07:10:03 GMT Message-Id: <201001300710.o0U7A3BJ028208@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Kevin Dorne Cc: Subject: Re: bin/142547: wpa_supplicant(8) drops connection on key renegotiation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Kevin Dorne List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jan 2010 07:10:03 -0000 The following reply was made to PR bin/142547; it has been noted by GNATS. From: Kevin Dorne To: Bernhard Schmidt Cc: bug-followup@freebsd.org Subject: Re: bin/142547: wpa_supplicant(8) drops connection on key renegotiation Date: Fri, 29 Jan 2010 23:09:05 -0800 Setting the router to use only WPA2 instead of the previous setting of WPA1 & WPA2 seemed to fix the problem. Please let me know if I can provide any more logs or assistance in isolating the bug. Thanks, -k From owner-freebsd-net@FreeBSD.ORG Sat Jan 30 08:25:14 2010 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 AC0C4106568B for ; Sat, 30 Jan 2010 08:25:14 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id 7B2648FC12 for ; Sat, 30 Jan 2010 08:25:14 +0000 (UTC) Received: from compute1.internal (compute1.internal [10.202.2.41]) by gateway1.messagingengine.com (Postfix) with ESMTP id C3C60CEE2F for ; Sat, 30 Jan 2010 03:25:13 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Sat, 30 Jan 2010 03:25:13 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=message-id:date:from:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; s=smtpout; bh=gs4/eJSyBuV8XtCPoXp7LfvNn3k=; b=ihxnlGFRFyDnQDIYCVvsrjydXtwJdhGu/Rw76tLCmF+LNRr4eFmSWAI2Lihuhe+NrdD4T9rVFccb4SjzX1vkF5t6qJ7o9Km3RKq2jjNwRjERb7tiinTRHn0GSe+CP0oQlDgPTCVhfRIjixdnObGNGHB5n6CUjxN7MM5c2ZoWdo8= X-Sasl-enc: L9ntU9YoirLbOytBo3XmiqDp8FwQeMh4fUfy4/0Yod7X 1264839913 Received: from anglepoise.lon.incunabulum.net (cpc2-dals7-0-0-cust253.hari.cable.virginmedia.com [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 604CF1A820 for ; Sat, 30 Jan 2010 03:25:13 -0500 (EST) Message-ID: <4B63ECE8.5000500@incunabulum.net> Date: Sat, 30 Jan 2010 08:25:12 +0000 From: Bruce Simpson User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.7) Gecko/20100124 Thunderbird/3.0.1 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <7609d8391001292011w32ffba13l9e1f94c59ce0d439@mail.gmail.com> In-Reply-To: <7609d8391001292011w32ffba13l9e1f94c59ce0d439@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: Tunneling in freeBSD 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, 30 Jan 2010 08:25:14 -0000 On 01/30/10 04:11, Nazeem نجم لدين wrote: > hi, > > Can you suggest way of getting a multicast tunnel work. The assumption is > that there is a unicast cloud in between two mbone networks. So we need to > forward the multicast traffic over the unicast tunnel. Application is for > video transmission. > Just configure up a gre(4) or gif(4) interface and specify to mrouted it's a 'phyint'. From owner-freebsd-net@FreeBSD.ORG Sat Jan 30 16:47:49 2010 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 797A5106566B for ; Sat, 30 Jan 2010 16:47:49 +0000 (UTC) (envelope-from jfb@mr-happy.com) Received: from vexbert.mr-paradox.net (vexbert.mr-paradox.net [IPv6:2001:470:b:28:f::1]) by mx1.freebsd.org (Postfix) with ESMTP id 5A5DC8FC0C for ; Sat, 30 Jan 2010 16:47:49 +0000 (UTC) Received: from crow.mr-happy.com (crow.mr-happy.com [10.1.0.2]) by vexbert.mr-paradox.net (Postfix) with ESMTP id 055E5845AD; Sat, 30 Jan 2010 11:47:48 -0500 (EST) Received: by crow.mr-happy.com (Postfix, from userid 16139) id 3F803BB84; Sat, 30 Jan 2010 11:47:48 -0500 (EST) Date: Sat, 30 Jan 2010 11:47:48 -0500 From: Jeff Blank To: Steven Hartland Message-ID: <20100130164748.GA71662@mr-happy.com> References: <20100129235911.GA67110@mr-happy.com> <398DD47A113342D78637D600C0C4C47B@multiplay.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <398DD47A113342D78637D600C0C4C47B@multiplay.co.uk> X-Face: #0jV*~a}VtKS-&E/!EJpH('H1Va}24dxF0oT&+.R3Gu8C; xhSC+<|+H84&YLbMvphuRT4cp3.|8EN_(2Eix/6{.Up~u`a^}0Ln&b+9Fw|BPig@-{y\pL_46d&ZwA]5%_AU?}DezfE&1!>H?3E$!Yve7.O<+..Jnb4:'6Ey_]FtFzU9=*l$1p/@gA,Ze>^5<]+r(XJ+m7`/vMDc$'wy|`e X-Virus-Scanned: ClamAV 0.94.2/10344/Sat Jan 30 03:57:10 2010 on vexbert.mr-paradox.net X-Virus-Status: Clean Cc: FreeBSD Net Subject: Re: kern/141646: [em] em(4) + lagg(4) + vlan(4) generatesISL-tagged frames instead of 802.1q-tagged frames 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, 30 Jan 2010 16:47:49 -0000 On Sat, Jan 30, 2010 at 01:47:31AM -0000, Steven Hartland wrote: > Since your using lagg there Jeff have you done on perf testing at > all, when I tested here dual em0 + lagg + lacp => cisco 6509 although > all seemed to negotiate correctly, balancing wasn't working at all. Haven't done any perf testing, but I'm using failover, not LACP. Jeff From owner-freebsd-net@FreeBSD.ORG Sat Jan 30 19:49:40 2010 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 01947106568B for ; Sat, 30 Jan 2010 19:49:40 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [IPv6:2001:4200:7000:2::1]) by mx1.freebsd.org (Postfix) with ESMTP id 346588FC18 for ; Sat, 30 Jan 2010 19:49:39 +0000 (UTC) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id 121E439825; Sat, 30 Jan 2010 21:49:37 +0200 (SAST) Date: Sat, 30 Jan 2010 21:49:37 +0200 From: John Hay To: Paul B Mahol Message-ID: <20100130194936.GA49220@zibbi.meraka.csir.co.za> References: <20091201104951.GA42629@zibbi.meraka.csir.co.za> <3a142e750912010740wc69464btbdeea834b0d4e516@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3a142e750912010740wc69464btbdeea834b0d4e516@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: wlan adhoc mode crash 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, 30 Jan 2010 19:49:40 -0000 On Tue, Dec 01, 2009 at 04:40:56PM +0100, Paul B Mahol wrote: > On 12/1/09, John Hay wrote: > > Hi, > > > > I'm not sure if this is the best list. > > > > I'm trying to get our Avila (arm) boards with atheros wireless cards > > upgraded from 7.2 to 8.0. We use adhoc mode and I get a panic in > > ieee80211_getcapinfo() because the chan pointer is 0xffff which seems > > to mean IEEE80211_CHAN_ANY in other places. So the question is, should > > ieee80211_getcapinfo() never be called with chan being 0xffff or should > > it know how to handle that case? > > IEEE80211_CHAN_ANY is there to mean no channel is selected, so you can not call > getcapinfo with such argument. I finally got back to this. I can panic an Avila ARM and a Wrap i386 board (8-stable based) with this sequence: /sbin/ifconfig wlan0 create wlandev ath0 wlanmode adhoc /sbin/ifconfig wlan0 country ZA /sbin/ifconfig wlan0 up /sbin/ifconfig wlan0 channel 132 ssid ptabb They do not panic immediately, but a few seconds later. It happens inside ieee80211_getcapinfo() and chan is 0xffff. Those ifconfig lines basically mimic the following rc.conf lines: wlans_ath0="wlan0" create_args_wlan0="wlanmode adhoc" ifconfig_wlan0="country ZA" ifconfig_wlan0_alias0="channel 132 ssid ptabb" #ipv6_prefix_wlan0="fd9c:6829:597c:10" If one move the "ifconfig wlan0 up" line down to after setting the channel and ssid, the panic does not happen. John -- John Hay -- jhay@meraka.csir.co.za / jhay@FreeBSD.org From owner-freebsd-net@FreeBSD.ORG Sat Jan 30 22:55:26 2010 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 65E63106566B for ; Sat, 30 Jan 2010 22:55:26 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id E4CEF8FC14 for ; Sat, 30 Jan 2010 22:55:25 +0000 (UTC) Received: by bwz5 with SMTP id 5so534214bwz.3 for ; Sat, 30 Jan 2010 14:55:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:to:cc:subject:references :organization:from:date:in-reply-to:message-id:user-agent :mime-version:content-type:content-transfer-encoding; bh=Y0V0Lz30NruI1BXyy8VP+uKbpxJghw4245ANV5KlJc8=; b=f61hC+A1OhfyuW8oIF9+5kPHTxqKa7JIpsial3Mepx+x04qpJxs4Jx3M5dnvhJti6j pICC2lNLoteASVgbUqB2GWR+TJjcBUcoqzRwaomSdocA3LRYhzzLwJuJAJKQHTXzWwtb rDfQWTLIqBAalHrXHp5BqfSn24UFvGNb4YCGc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=to:cc:subject:references:organization:from:date:in-reply-to :message-id:user-agent:mime-version:content-type :content-transfer-encoding; b=Igdg/uHA48wJ0ug9cBYEFABp1C8xyRiWou9G36PKmxvNxr1qnzEudWXBUhf8K1mqa9 ec6zTFDrLHUKBNLC96PcFRPWbr8wL7HzGwif7E1GJ4t8aO/b5HmDJdSVOC/9BYB+wH6K BkuqYSfSXTGngiwD05m8UC1qPZl2FLKUYsYnQ= Received: by 10.204.141.3 with SMTP id k3mr1701666bku.48.1264892124700; Sat, 30 Jan 2010 14:55:24 -0800 (PST) Received: from localhost ([95.69.161.2]) by mx.google.com with ESMTPS id 13sm1481070bwz.6.2010.01.30.14.55.22 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 30 Jan 2010 14:55:23 -0800 (PST) To: Alan Aldrich References: Organization: TOA Ukraine From: Mikolaj Golub Date: Sun, 31 Jan 2010 00:55:21 +0200 In-Reply-To: (Alan Aldrich's message of "Thu\, 28 Jan 2010 08\:46\:33 -0800") Message-ID: <86wryzurs6.fsf@kopusha.onet> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org Subject: Re: NFS mount properties 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, 30 Jan 2010 22:55:26 -0000 On Thu, 28 Jan 2010 08:46:33 -0800 Alan Aldrich wrote: > I am trying to determine how to examine the actual properties of an > nfs mount in FreeBSD > In CentOS one can 'cat /proc/mounts' to determine all of the mount > properties. > Specifically I am trying to confirm whether the mount is using TCP or > UDP as I want it to > be TCP . Is there some similar way to tell in FreeBSD? > > My fstab entry says this > 192.168.44.55:/mcp/home /net nfs rw,async,-d,-3,-s,-i,noatime,- > T 0 0 > It mounts fine, > but I want to confirm that it is actually mounting with TCP and not > UDP and cannot figure out > what tool will tell me this. > > 'mount' tells me this > 192.168.44.55:/mcp/home on /net (nfs, asynchronous, noatime) > > but not whether it is mounted TCP or UDP If it is mounted with TCP u UDP you can find out with netstat, checking tcp connections to 2049 port. If you see established connections like below tcp4 0 0 10.0.0.110.895 10.0.100.2.2049 ESTABLISHED then tcp is used. Certainly if you have several mounts on the same ip it complicates the situation :-) I don't know any such tools that would report this info and would glad to hear about them, but if I really needed this info I could use the universal tool -- kgdb :-) zhuzha:~% sudo kgdb (kgdb) set print pretty (kgdb) p *mountlist.tqh_first.mnt_list.tqe_next.mnt_list.tqe_next.mnt_list.tqe_next.mnt_list.tqe_next.mnt_list.tqe_next.mnt_list.tqe_next $26 = { ... mnt_list = { tqe_next = 0xc5e9a78c, tqe_prev = 0xc5e9acac }, ... mnt_opt = 0xc61f7760, ... mnt_stat = { f_version = 537068824, f_type = 4, f_flags = 0, f_bsize = 512, f_iosize = 32768, f_blocks = 284354052, f_bfree = 137997300, f_bavail = 115248976, f_files = 18394110, f_ffree = 16921938, f_syncwrites = 0, f_asyncwrites = 0, f_syncreads = 0, f_asyncreads = 0, f_spare = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0}, f_namemax = 255, f_owner = 0, f_fsid = { val = {67174148, 4} }, f_charspare = '\0' , f_fstypename = "nfs", '\0' , f_mntfromname = "srv01.ua1:/var/public\000\004(\000\000\000\000\000\214\004\b\003\000\000\000\003\000\000\000P\000\000\000X\002\000\000\200»\000\000\000ÐBÆ\000\000\000\000 \a \aÀ\a7Æ \a7ÆÀx\037Æ°x\037Æ\004\000\000\000\v\000\000", f_mntonname = "/mnt/0", '\0' }, ... } (kgdb) p *mountlist.tqh_first.mnt_list.tqe_next.mnt_list.tqe_next.mnt_list.tqe_next.mnt_list.tqe_next.mnt_list.tqe_next.mnt_list.tqe_next.mnt_opt.tqh_first $27 = { link = { tqe_next = 0xc6370560, tqe_prev = 0xc61f7760 }, name = 0xc61f7770 "rw", value = 0xc61f7780, len = 1, pos = 0, seen = 0 } (kgdb) p *mountlist.tqh_first.mnt_list.tqe_next.mnt_list.tqe_next.mnt_list.tqe_next.mnt_list.tqe_next.mnt_list.tqe_next.mnt_list.tqe_next.mnt_opt.tqh_first.link.tqe_next $28 = { link = { tqe_next = 0xc6370580, tqe_prev = 0xc6370520 }, name = 0xc61f77a0 "soft", value = 0xc61f77b0, len = 1, pos = 1, seen = 1 } (kgdb) p *mountlist.tqh_first.mnt_list.tqe_next.mnt_list.tqe_next.mnt_list.tqe_next.mnt_list.tqe_next.mnt_list.tqe_next.mnt_list.tqe_next.mnt_opt.tqh_first.link.tqe_next.link.tqe_next $29 = { link = { tqe_next = 0xc63705a0, tqe_prev = 0xc6370560 }, name = 0xc61f77c0 "intr", value = 0xc61f7810, len = 1, pos = 2, seen = 1 } (kgdb) p *mountlist.tqh_first.mnt_list.tqe_next.mnt_list.tqe_next.mnt_list.tqe_next.mnt_list.tqe_next.mnt_list.tqe_next.mnt_list.tqe_next.mnt_opt.tqh_first.link.tqe_next.link.tqe_next.link.tqe_next $30 = { link = { tqe_next = 0xc63705e0, tqe_prev = 0xc6370580 }, name = 0xc61f77d0 "rsize", value = 0xc61f77e0, len = 6, pos = 3, seen = 1 } (kgdb) p *mountlist.tqh_first.mnt_list.tqe_next.mnt_list.tqe_next.mnt_list.tqe_next.mnt_list.tqe_next.mnt_list.tqe_next.mnt_list.tqe_next.mnt_opt.tqh_first.link.tqe_next.link.tqe_next.link.tqe_next.link.tqe_next $31 = { link = { tqe_next = 0xc6370620, tqe_prev = 0xc63705a0 }, name = 0xc61f77f0 "wsize", value = 0xc61f7800, len = 6, pos = 4, seen = 1 } (kgdb) p *mountlist.tqh_first.mnt_list.tqe_next.mnt_list.tqe_next.mnt_list.tqe_next.mnt_list.tqe_next.mnt_list.tqe_next.mnt_list.tqe_next.mnt_opt.tqh_first.link.tqe_next.link.tqe_next.link.tqe_next.link.tqe_next.link.tqe_next $32 = { link = { tqe_next = 0xc6370640, tqe_prev = 0xc63705e0 }, name = 0xc61f7820 "tcp", value = 0xc61f7830, len = 1, pos = 5, seen = 1 } If I needed to do this frequently I would write a gdb script taking as an example nice scripts from jhb :-) http://people.freebsd.org/~jhb/gdb/ -- Mikolaj Golub