From owner-freebsd-net@FreeBSD.ORG Sun Jul 18 12:18:27 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 D41E41065672; Sun, 18 Jul 2010 12:18:27 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id AB6F58FC14; Sun, 18 Jul 2010 12:18:27 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o6ICIRQr096516; Sun, 18 Jul 2010 12:18:27 GMT (envelope-from gavin@freefall.freebsd.org) Received: (from gavin@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o6ICIRox096512; Sun, 18 Jul 2010 12:18:27 GMT (envelope-from gavin) Date: Sun, 18 Jul 2010 12:18:27 GMT Message-Id: <201007181218.o6ICIRox096512@freefall.freebsd.org> To: samspeed@mail.ru, gavin@FreeBSD.org, gavin@FreeBSD.org, freebsd-net@FreeBSD.org From: gavin@FreeBSD.org Cc: Subject: Re: amd64/145654: amd64-curent memory leak in kernel 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, 18 Jul 2010 12:18:27 -0000 Synopsis: amd64-curent memory leak in kernel State-Changed-From-To: feedback->open State-Changed-By: gavin State-Changed-When: Sun Jul 18 12:07:52 UTC 2010 State-Changed-Why: Feedback was received Responsible-Changed-From-To: gavin->freebsd-net Responsible-Changed-By: gavin Responsible-Changed-When: Sun Jul 18 12:07:52 UTC 2010 Responsible-Changed-Why: I can't actually spot anything out of the ordinary in the data received but this does sound very much like it is either some sort of network leak (or maybe ipfw?) - pass over to the -net guys who may have more of an idea or see something that I've missed. http://www.freebsd.org/cgi/query-pr.cgi?pr=145654 From owner-freebsd-net@FreeBSD.ORG Sun Jul 18 15:42: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 4AE891065675; Sun, 18 Jul 2010 15:42:45 +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 226218FC1D; Sun, 18 Jul 2010 15:42:44 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o6IFgifi000734; Sun, 18 Jul 2010 15:42:44 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o6IFgiYI000730; Sun, 18 Jul 2010 15:42:44 GMT (envelope-from linimon) Date: Sun, 18 Jul 2010 15:42:44 GMT Message-Id: <201007181542.o6IFgiYI000730@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/147894: [ipsec] IPv6-in-IPv4 does not work inside an ESP-only IPsec tunnel 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, 18 Jul 2010 15:42:45 -0000 Old Synopsis: IPv6-in-IPv4 does not work inside an ESP-only IPsec tunnel New Synopsis: [ipsec] IPv6-in-IPv4 does not work inside an ESP-only IPsec tunnel Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun Jul 18 15:42:23 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=147894 From owner-freebsd-net@FreeBSD.ORG Mon Jul 19 03:29: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 1D6D6106566C; Mon, 19 Jul 2010 03:29:07 +0000 (UTC) (envelope-from marcus@freebsd.org) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by mx1.freebsd.org (Postfix) with ESMTP id CD1498FC13; Mon, 19 Jul 2010 03:29:06 +0000 (UTC) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o6J3HlDR005770; Sun, 18 Jul 2010 23:17:47 -0400 (EDT) Received: from 99-206-38-97.pools.spcsdns.net (jclarke-pc.cisco.com [172.18.254.236]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o6J3HiW0003891; Sun, 18 Jul 2010 23:17:45 -0400 (EDT) Message-ID: <4C43C3D7.3050306@freebsd.org> Date: Sun, 18 Jul 2010 23:17:43 -0400 From: Joe Marcus Clarke Organization: FreeBSD, Inc. User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: weongyo@freebsd.org References: <201007102202.o6AM2hMs014094@freefall.freebsd.org> In-Reply-To: <201007102202.o6AM2hMs014094@freefall.freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: kern/144724: [bwn] if_bwn does not pass traffic when in PIO mode 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, 19 Jul 2010 03:29:07 -0000 On 7/10/10 6:02 PM, weongyo@FreeBSD.org wrote: > Synopsis: [bwn] if_bwn does not pass traffic when in PIO mode > > State-Changed-From-To: open->feedback > State-Changed-By: weongyo > State-Changed-When: Sat Jul 10 21:59:44 UTC 2010 > State-Changed-Why: > Today a patch for LP PHY is committed into the tree. I think the > issue was same with your device. Could you please test with r209888 > again? > > > Responsible-Changed-From-To: freebsd-net->weongyo > Responsible-Changed-By: weongyo > Responsible-Changed-When: Sat Jul 10 21:59:44 UTC 2010 > Responsible-Changed-Why: > Today a patch for LP PHY is committed into the tree. I think the > issue was same with your device. Could you please test with r209888 > again? > > http://www.freebsd.org/cgi/query-pr.cgi?pr=144724 > So far, I haven't seen the interface fail. I do see a lot of decryption error messages on the console, but that doesn't appear to be affecting functionality. Joe -- Joe Marcus Clarke FreeBSD GNOME Team :: gnome@FreeBSD.org FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome From owner-freebsd-net@FreeBSD.ORG Mon Jul 19 11:07:02 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 64AC71065670 for ; Mon, 19 Jul 2010 11:07:02 +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 5243A8FC19 for ; Mon, 19 Jul 2010 11:07:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o6JB726x065782 for ; Mon, 19 Jul 2010 11:07:02 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o6JB71Qq065780 for freebsd-net@FreeBSD.org; Mon, 19 Jul 2010 11:07:01 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 19 Jul 2010 11:07:01 GMT Message-Id: <201007191107.o6JB71Qq065780@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, 19 Jul 2010 11:07:02 -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/148322 net [ath] Triggering atheros wifi beacon misses in hostap o kern/148317 net [ath] FreeBSD 7.x hostap memory leak in net80211 or At o kern/148155 net [vimage] Kernel panic with PF/IPFilter + VIMAGE kernel o kern/148112 net [ath] Atheros 9285 cannot register with wifi AP (timeo o kern/148108 net [bge] FreeBSD 7.2 or 8.0 does not recognize, 4.11 can o kern/148078 net [ath] wireless networking stops functioning o kern/148004 net [em] Inconsistent networking with em driver on FreeBSD o kern/147989 net [em] em Receive errors / CRC Errors / Alignment Errors o kern/147985 net [alc] alc network driver + tso ( + vlan ? ) does not w o kern/147894 net [ipsec] IPv6-in-IPv4 does not work inside an ESP-only o kern/147862 net [wpi] Possible bug in the wpi driver. Network Manager o kern/147824 net [msk]: watchdog timeouts & Tx descriptor error o kern/147684 net [nfe] nVidia MCP55 driver blocks IPMI LAN on load o kern/147352 net [netinet] [patch] replace printf() with log() for "Lim o kern/147245 net [dummynet] dummynet skip traffic over configured limit o kern/147155 net [ip6] setfb not work with ipv6 o kern/146909 net [rue] rue(4) does not detect OQO model01 network contr o kern/146845 net [libc] close(2) returns error 54 (connection reset by o kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146759 net [cxgb] [patch] cxgb panic calling cxgb_set_lro() witho o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146628 net [tcp] [patch] TCP does not clear DF when MTU is below o kern/146539 net [arp] arp pub not working properly o kern/146534 net [icmp6] wrong source address in echo reply o kern/146517 net [ath] [wlan] device timeouts for ath wlan device on re o kern/146427 net [mwl] Additional virtual access points don't work on m o kern/146426 net [mwl] 802.11n rates not possible on mwl o kern/146425 net [mwl] mwl dropping all packets during and after high u f kern/146394 net [vlan] IP source address for outgoing connections o bin/146377 net [ppp] [tun] Interface doesn't clear addresses when PPP o kern/146358 net [vlan] wrong destination MAC address o kern/146263 net [em] [panic] Panic in em(4) SIOCADDMULTI/em_set_multi/ o kern/146250 net [netinet] [patch] Races on interface alias removal o kern/146165 net [wlan] [panic] Setting bssid in adhoc mode causes pani o kern/146082 net [ng_l2tp] a false invaliant check was performed in ng_ o kern/146037 net [panic] mpd + CoA = kernel panic o kern/145826 net [ath] Unable to configure adhoc mode on ath0/wlan0 o kern/145825 net [panic] panic: soabort: so_count o kern/145777 net [wpi] Intel 3945ABG driver breaks the connection after o kern/145728 net [lagg] Stops working lagg between two servers. o amd64/145654 net amd64-curent memory leak in kernel o kern/144987 net [wpi] [panic] injecting packets with wlaninject using o kern/144898 net [wpi] [panic] wpi panics system o kern/144882 net MacBookPro =>4.1 does not connect to BSD in hostap wit o kern/144874 net [if_bridge] [patch] if_bridge frees mbuf after pfil ho o kern/144777 net [arp] proxyarp broken in 8.0 [regression] o kern/144755 net [iwi] [panic] iwi panic when issuing /etc/rc.d/netif r o conf/144700 net [rc.d] async dhclient breaks stuff for too many people o kern/144680 net [em] em(4) problem with dual-port adapter o kern/144642 net [rum] [panic] Enabling rum interface causes panic o kern/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 o kern/144572 net [carp] CARP preemption mode traffic partially goes to o kern/144561 net [ixgbe] [patch] ixgbe driver errors o kern/144505 net [bwn] [patch] Error in macro CALC_COEFF2. f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/144206 net Marvell Yukon NIC not working under FreeBSD o kern/144000 net [tcp] setting TCP_MAXSEG by setsockopt() does not seem o kern/143939 net [ipfw] [em] ipfw nat and em interface rxcsum problem o kern/143874 net [wpi] Wireless 3945ABG error. wpi0 could not allocate o kern/143868 net [ath] [patch] allow Atheros watchdog timeout to be tun o kern/143846 net [gif] bringing gif3 tunnel down causes gif0 tunnel to s kern/143673 net [stf] [request] there should be a way to support multi s kern/143666 net [ip6] [request] PMTU black hole detection not implemen o kern/143622 net [pfil] [patch] unlock pfil lock while calling firewall o kern/143595 net [wpi] [panic] Creating virtual interface over wpi0 in o kern/143593 net [ipsec] When using IPSec, tcpdump doesn't show outgoin o kern/143591 net [ral] RT2561C-based DLink card (DWL-510) fails to work o kern/143573 net [em] em(4) NIC crashes intermittently o kern/143285 net [em] [regression] jumbo frames broken in 8.0 o kern/143208 net [ipsec] [gif] IPSec over gif interface not working o conf/143079 net hostapd(8) startup missing multi wlan functionality o kern/143074 net [wi]: wi driver triggers panic 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/142772 net [libc] lla_lookup: new lle malloc failed o kern/142766 net [ipw] [regression] ipw(4) with Intel PRO/wireless 2100 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/141696 net [rum] [panic] rum(4)+ vimage = kernel panic 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/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/140682 net [netgraph] [panic] random panic in netgraph 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 o kern/140597 net [netinet] [patch] implement Lost Retransmission Detect 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/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 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 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 if_adata/ 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 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/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/136426 net [panic] spawning several dhclients in parallel panics o kern/136168 net [em] em driver initialization fails on Intel 5000PSL m 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] Route messages sent to all socket listeners re 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/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 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 [patch] rc.conf(5): allow to setfib(1) for service run 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/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/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/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) 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 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/124225 net [ndis] [patch] ndis network driver sometimes loses net o kern/124160 net [libc] connect(2) function loops indefinitely 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 kern/123758 net [panic] panic while restarting net/freenet6 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/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 ieee 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/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 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/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 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 conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106444 net [netgraph] [panic] Kernel Panic on Binding to an ip to 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/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o kern/102540 net [netgraph] [patch] supporting vlan(4) by ng_fec(4) 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 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/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 o kern/87421 net [netgraph] [panic]: ng_ether + ng_eiface + if_bridge 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/86427 net [lor] Deadlock with FASTIPSEC and nat 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/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 kern/82881 net [netgraph] [panic] ng_fec(4) causes kernel panic after 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/81095 net IPsec connection stops working if associated network i 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/78968 net FreeBSD freezes on mbufs exhaustion (network interface 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 a kern/71474 net [route] route lookup does not skip interfaces marked d 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/66225 net [netgraph] [patch] extend ng_eiface(4) control message o kern/65616 net IPSEC can't detunnel GRE packets after real ESP encryp s kern/60293 net [patch] FreeBSD arp poison patch a kern/56233 net IPsec tunnel (ESP) over IPv6: MTU computation is wrong o kern/54383 net [nfs] [patch] NFS root configurations without dynamic 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 432 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Jul 19 08:59: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 A81C31065679 for ; Mon, 19 Jul 2010 08:59:53 +0000 (UTC) (envelope-from beezarliu@yahoo.com.cn) Received: from n15.bullet.mail.mud.yahoo.com (n15.bullet.mail.mud.yahoo.com [68.142.206.42]) by mx1.freebsd.org (Postfix) with SMTP id 64F528FC13 for ; Mon, 19 Jul 2010 08:59:53 +0000 (UTC) Received: from [68.142.200.221] by n15.bullet.mail.mud.yahoo.com with NNFMP; 19 Jul 2010 08:59:52 -0000 Received: from [68.142.201.252] by t9.bullet.mud.yahoo.com with NNFMP; 19 Jul 2010 08:59:52 -0000 Received: from [127.0.0.1] by omp413.mail.mud.yahoo.com with NNFMP; 19 Jul 2010 08:59:52 -0000 X-Yahoo-Newman-Id: 721200.97150.bm@omp413.mail.mud.yahoo.com Received: (qmail 20150 invoked from network); 19 Jul 2010 08:59:52 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.cn; h=DKIM-Signature:Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Date:From:To:Cc:Subject:Message-ID:X-mailer:Mime-Version:Content-Type; b=vbni/156fGpSZdzB+TxLPMlR/C7bgSxZ+wMs66xXVNGZwc+3y9NMXkVfesxZyVOZFzVEi8MK3x4DQkNZLx1ukJ3uRrKMtFAJ9PyMXNrguFwChYQu7Upw/rVTtyw4quEbqLfJ7naMW3/ieUz0pxSObRQEaZ+5eiu4dBxfSjqKxLg= ; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.cn; s=s1024; t=1279529992; bh=qnQgj+ouusPTiXhfhDMKzGjNQ4c47Qndl/rJD13vDNE=; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Date:From:To:Cc:Subject:Message-ID:X-mailer:Mime-Version:Content-Type; b=sm+hBMENvYZEVRV3cSVDAlrhb2tNbyZpU6XBkaiWqUwWTSh3RTKtyh4UFadTJSHWTLRUReZHUSAIy3755Qv8xeoOFDOUtbMrV7jlrJ1ZRG2VcGxF+DMs/2OlSeA1+07mWdrQv5K38LqNA+0Wasf4Jt4b49Oy7t6wv9Flg9FF0DA= Received: from PC-200811131239 (beezarliu@124.207.251.123 with login) by smtp119.plus.mail.sp1.yahoo.com with SMTP; 19 Jul 2010 01:59:51 -0700 PDT X-Yahoo-SMTP: YP5UPy2swBBHZGZlvbmOrntlD3fotw-- X-YMail-OSG: mxQymrEVM1mEV9Tth36MFxOC4TTuoaPbZqbmJPSoG30nJsF FqI00GxJOwu5nYDzpZdcrKnV8ZsQggJ_4WWm5LmFg.mc4FRvtT9psUgB4kva x4dB4zRprjnkHy8Ag1i85HtHx8sy_xw4nHWxkBc50119BtQ6gAbv5KJ.ilWt yXTbNwNUcIRLmdPy2qh6YYyYX2q4fYHOZeed4.ATbqIWvoLF8xqHj3X9hC8g 7FQjkyN3V5afFRBbzYZpYqE4nia2u X-Yahoo-Newman-Property: ymail-3 Date: Mon, 19 Jul 2010 16:59:49 +0800 From: "beezarliu" To: "freebsd-net" Message-ID: <201007191659457506137@yahoo.com.cn> X-mailer: Foxmail 6, 10, 201, 20 [cn] Mime-Version: 1.0 X-Mailman-Approved-At: Mon, 19 Jul 2010 11:11:10 +0000 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Jack Vogel Subject: igb statistics error 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, 19 Jul 2010 08:59:53 -0000 Hi Jack and Hackers, I use igb driver (version:1.9.3) in our local-made freebsd7-stable build. But I found its statistics is very strang. The total received packet number(TPR) is not equal to the good packets Rx count (GPRC). I think these 2 values should be equal because there is no error in receiving side. For example: (kgdb) p adapter.stats $4 = {crcerrs = 0, algnerrc = 0, symerrs = 0, rxerrc = 0, mpc = 0, scc = 0, ecol = 0, mcc = 0, latecol = 0, colc = 0, dc = 0, tncrs = 0, sec = 0, cexterr = 0, rlec = 0, xonrxc = 0, xontxc = 0, xoffrxc = 0, xofftxc = 0, fcruc = 0, prc64 = 6, prc127 = 23, prc255 = 0, prc511 = 0, prc1023 = 0, prc1522 = 0, gprc = 29, bprc = 29, mprc = 0, gptc = 0, gorc = 1948, gotc = 0, rnbc = 0, ruc = 0, rfc = 0, roc = 0, rjc = 0, mgprc = 0, mgpdc = 0, mgptc = 0, tor = 0, tot = 0, tpr = 568, tpt = 0, ptc64 = 0, ptc127 = 0, ptc255 = 0, ptc511 = 0, ptc1023 = 0, ptc1522 = 0, mptc = 0, bptc = 0, tsctc = 0, tsctfc = 0, iac = 0, icrxptc = 0, icrxatc = 0, ictxptc = 0, ictxatc = 0, ictxqec = 0, ictxqmtc = 0, icrxdmtc = 0, icrxoc = 0, cbtmpc = 0, htdpmc = 0, cbrdpc = 0, cbrmpc = 0, rpthc = 0, hgptc = 0, htcbdpc = 0, hgorc = 0, hgotc = 0, lenerrs = 0, scvpc = 0, hrmpc = 0, doosync = 0, lostcarrier = 0, skip_wakeup = 0, wakeup = 0, getbuffail = 0, eop = 0, m_flagserr = 0, m_lenserr = 0, rcviferr = 0} 2010-07-19 beezarliu From owner-freebsd-net@FreeBSD.ORG Mon Jul 19 15:24: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 27ACD106564A for ; Mon, 19 Jul 2010 15:24:40 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id B0A468FC17 for ; Mon, 19 Jul 2010 15:24:39 +0000 (UTC) Received: by eyh6 with SMTP id 6so1146222eyh.13 for ; Mon, 19 Jul 2010 08:24:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=9zg0Y1tFDykWRpMoJhO3fBs0JUftAEN26gBlpP4yEaw=; b=fPq24nyrAQAswQkFPm6MXirJ3rmUSRRoa2VKruejXPnQsgZ1LP1SFigUXLV87MA2I8 YzId7nB7F4QLRDHTuYoxy720+iRkefSe35BiAvJknfg/bel7E2mWwfi0waFTeIBz8XsF K1EqYm1v+7hinNKUCg3FcCQB6HTSl+G+Tq920= 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=mRvodBYDmRqNCxVMlvcDFjPJ2HjI9DAWfMA0qHC1KRKdjNvUCVA5HQFJ384fBfcjEX kgz65AW9YAhjBJiiU6GsHBC1nk93xGfFkECWuaKbW7s05cO5cKuFxUaadQff3PmvtyYA FYIN06EIK26LcaeEd+KmMeeGbPG4NuYUZJ6Ec= MIME-Version: 1.0 Received: by 10.213.27.68 with SMTP id h4mr108526ebc.98.1279553078708; Mon, 19 Jul 2010 08:24:38 -0700 (PDT) Received: by 10.213.113.195 with HTTP; Mon, 19 Jul 2010 08:24:38 -0700 (PDT) In-Reply-To: <201007191659457506137@yahoo.com.cn> References: <201007191659457506137@yahoo.com.cn> Date: Mon, 19 Jul 2010 11:24:38 -0400 Message-ID: From: Ryan Stone To: beezarliu Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net , Jack Vogel Subject: Re: igb statistics error 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, 19 Jul 2010 15:24:40 -0000 If you look at the datasheet you will see that the statistics do not measure the same thing(why would Intel implement two hardware counters that measure the same thing?). The Good Packets Received Count measures the number of valid packets that passed one of the receive filters. In other words, it measures the number of valid packets that were addressed to that interface. The Total Packets Received statistic measures the total number of valid packets received, including packets that do not pass any filters. In other words, it measures the number of (valid?) packets received by the interface, whether or not they were addressed to it. From owner-freebsd-net@FreeBSD.ORG Mon Jul 19 19:26: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 16FE81065675; Mon, 19 Jul 2010 19:26:30 +0000 (UTC) (envelope-from shteryana@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3EBE48FC14; Mon, 19 Jul 2010 19:26:28 +0000 (UTC) Received: by fxm13 with SMTP id 13so2633863fxm.13 for ; Mon, 19 Jul 2010 12:26:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:reply-to:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=jC7qF01OKQIeqY9e84EGO//fnZeChV/fNhWH2t4tiRo=; b=eho9dDxGBlHS8FrSWkLqyRjWJzzB/ZNQ8WowdN5NyeCDOtN+tauHqFfp1mwezDyIrj pFnZOQDikWIxaAVpgF2x1aoBylF0PaBHqvSJjbukvhPnOlAfIs/7YBU7RoVl++PQuxbv TvTlCo095K69exMloez0vJq/uPnBE7uAAmDlc= 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=jnYzLRqbO4Su3nqYxLXWsIvBwV+SKL3o4zdX3TMdwftJ7hmU1rQyvDkkwubW1Ek7up Aly4wauM60VDI0rsJXdxKgRk9mijgfYbar8CwnKuEtIBlstcSVTxEXgFqFEf7PL6eoy6 lbt+0ZrxTqQGNSWJ47qt4cOLNWyZx33vvAniY= MIME-Version: 1.0 Received: by 10.223.104.148 with SMTP id p20mr4272156fao.11.1279567587972; Mon, 19 Jul 2010 12:26:27 -0700 (PDT) Sender: shteryana@gmail.com Received: by 10.223.113.10 with HTTP; Mon, 19 Jul 2010 12:26:27 -0700 (PDT) In-Reply-To: References: Date: Mon, 19 Jul 2010 22:26:27 +0300 X-Google-Sender-Auth: -ox1kBeG0n3l5n9nfAxPr3JCgeM Message-ID: From: Shteryana Shopova To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-net@FreeBSD.org" , freebsd-current@freebsd.org Subject: Re: Call for testers: wireless module for bsnmpd(1) 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: Mon, 19 Jul 2010 19:26:30 -0000 Hi all, Thanks for the feedback and comments. I've uploaded an updated tarball at http://people.freebsd.org/~syrinx/snmp/snmp_wlan-20100719-01.tar . On Sun, Jul 11, 2010 at 8:23 PM, Gabor PALI wrote: > > A few comments: > > - I think there should be bsnmpd(1) instead of bsnmpd(8) in the NAME > section of snmp_wlan(3). Fixed in the latest sources. > - It creates an "/usr/lib/snmp_wlan.so." file which seems a bit strange > for me. Yes, indeed - this weird naming happens when an bsnmp module is built outside the source tree and SHLIB_MAJOR is not defined - the file names a module based on snmp_${MOD}.so.${SHLIB_MAJOR} - this should be resolved once the module is made part of the source tree. > - It produces the following on my machine: > > snmpd[3871]: SNMP wlan loaded wlan_wlan_acl module > snmpd[3871]: send: Connection refused > snmpd[3871]: iface wlan0 - get param: ioctl(41) failed: Invalid argument > snmpd[3871]: iface wlan0 - get param: ioctl(41) failed: Invalid argument > snmpd[3871]: iface wlan0 - get param: ioctl(41) failed: Invalid argument > snmpd[3871]: iface wlan0 - get param: ioctl(41) failed: Invalid argument > This is because ioctl(wname, IEEE80211_IOC_MACCMD, ...) returns EINVAL when no MAC ACL policy has been configured in the interface - should be resolved in the latest sources. > On Wed, Jul 14, 2010 at 5:40 AM, Adrian Chadd wrote: > Howdy! > > Compiling this on MIPS gives this error: > > Warning: Object directory not changed from original /usr/home/adrian/w/snmp_wlan > cc -fpic -DPIC -O -pipe -EB -msoft-float -G0 -mno-dsp -mabicalls > -DSNMPTREE_TYPES -g -I. -std=gnu99 -Wsystem-headers -Werror -Wall > -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual > -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter > -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls > -Wold-style-definition -Wno-pointer-sign -c wlan_sys.c -o wlan_sys.So > cc1: warnings being treated as errors > wlan_sys.c: In function 'wlan_get_scan_results': > wlan_sys.c:2221: warning: cast increases required alignment of target type > wlan_sys.c: In function 'wlan_get_peerinfo': > wlan_sys.c:2713: warning: cast increases required alignment of target type > *** Error code 1 > In the latest sources, I replaced the cast with memcopy's which shold fix the errors, but I haven't tested it since I don't have a MIPS platform to test. It'll be good to know the errors have been actually fixed. > On Wed, Jul 14, 2010 at 6:16 AM, Adrian Chadd wrote: > I've already emailed you about the alignment warnings. > > The returned error value is an SNMPv2 error (SNMP_ERR_INCONS_VALUE) > which causes v1 requests to error out. Is it at all possible to return > something valid if a v1 request is made? The SNMP_ERR_INCONS_VALUE is only returned in responce to SET requests when the value requested for SET is not valid - in such case if the packet is SNMPv1 packet the SNMP agent should itself replace any SNMPv2 error code with a corresponding SNMPv1 code (e.g SNMP_ERR_BADVALUE should be returned instead of SNMP_ERR_INCONS_VALUE); could you please specify your agent config and what exact client command and aparameters are you issueing to produce the problem. > > snmpwalk'ing to inspect what -is- returned fails, even when querying in v2 mode: > > BEGEMOT-WIRELESS-MIB::wlanIfaceDot11nRIFS."wlan0" = INTEGER: false(2) > BEGEMOT-WIRELESS-MIB::wlanIfaceDot11nShortGI."wlan0" = INTEGER: false(2) > BEGEMOT-WIRELESS-MIB::wlanIfaceDot11nSMPSMode."wlan0" = INTEGER: disabled(1) > Error in packet. > Reason: (genError) A general failure occured > Failed object: BEGEMOT-WIRELESS-MIB::wlanIfaceDot11nSMPSMode."wlan0" > > The daemon logs errors when features aren't supported by the > underlying driver (eg querying TDMA stats on a non-TDMA interface.) > This may hide any actual underlying issues. This shouldn't be the case - the module reads each wlan parent capabilities and a relevant setting is only attempted in the kernel, only if the parent/wlan iterface capabilities indicate it is supported. I'm trying to test it on my system, but I don't see a problem. Again, could you please specify your kernel config, hardware wireless card, FreeBSD vsersion and the commands that you're running to create the problem. > > It isn't immediately clear which parameters are related to station and > which are related to hostap. Eg, wlanIfaceBeaconMissedThreshold. Is > that the station threshold or the AP threshold? Would it be worthwhile > creating separate branches for different stat types (station, ap, TDMA > AP, dot11n stuff, etc, etc?) rather than whacking it all together in > one tree? > The description of each object (and specifically under the wlanIfaceConfigTable table) in the BEGEMOT-WIRELESS-MIB.txt specifies whether the relevant object is meaningfull for interfaces in station or ap mode. I've thought about splitting the configuration in separate tables, but then there seven modes, not only station and host ap, and many objects are relevant for interfaces operating in any mode, so I decided to keep them in a common table. > I've not seen binary string indexing values on tables before. Eg: > > BEGEMOT-WIRELESS-MIB::wlanIfacePeerAddress."wlan0".'...$..'.61 = > STRING: 0:11:24:c7:e4:3d > BEGEMOT-WIRELESS-MIB::wlanIfacePeerAddress."wlan0".'..#2'.'.219 = > STRING: 0:23:32:27:fc:db > BEGEMOT-WIRELESS-MIB::wlanIfacePeerAssociationId."wlan0".'...$..'.61 = > INTEGER: 2 > BEGEMOT-WIRELESS-MIB::wlanIfacePeerAssociationId."wlan0".'..#2'.'.219 > = INTEGER: 1 > > Is that going to be portable to different utilities? Some of the code > I've seen (and written!) expect numeric table indexes rather than what > I see above. > No, it's not uncommon to have binary strings as indexes, as it is also not uncommon to have several indexes for an entry - for example dot1dTpFdbTable (BRIDGE-MIB, RFC 4188) is indexed by the entry's MAC address, mgmdHostSrcListTable (MGMD-STD-MIB, RFC 5519) is indexed by address type (IPv4 or IPv6), a multicast group address, a interface index and a host ip address (again either IPv4 or IPv6). Many other examples may be given in standartized MIBs and no software should rely on having SNMP tables indexed by a single integer index. cheers, Shteryana From owner-freebsd-net@FreeBSD.ORG Mon Jul 19 20:01:00 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 E7D4D1065674; Mon, 19 Jul 2010 20:01:00 +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 BD7F78FC20; Mon, 19 Jul 2010 20:01:00 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o6JK108p036773; Mon, 19 Jul 2010 20:01:00 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o6JK10Zf036764; Mon, 19 Jul 2010 20:01:00 GMT (envelope-from linimon) Date: Mon, 19 Jul 2010 20:01:00 GMT Message-Id: <201007192001.o6JK10Zf036764@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/148772: [alc] alc0 does not send/receive packets if not plugged in during boot 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, 19 Jul 2010 20:01:01 -0000 Old Synopsis: alc0 does not send/receive packets if not plugged in during boot New Synopsis: [alc] alc0 does not send/receive packets if not plugged in during boot Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Jul 19 20:00:38 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=148772 From owner-freebsd-net@FreeBSD.ORG Mon Jul 19 20:10:07 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 46C3C106566B for ; Mon, 19 Jul 2010 20:10:07 +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 1BC9D8FC16 for ; Mon, 19 Jul 2010 20:10:07 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o6JKA77V037914 for ; Mon, 19 Jul 2010 20:10:07 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o6JKA6JF037909; Mon, 19 Jul 2010 20:10:06 GMT (envelope-from gnats) Date: Mon, 19 Jul 2010 20:10:06 GMT Message-Id: <201007192010.o6JKA6JF037909@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Kurt Jaeger Cc: Subject: Re: kern/148772: alc0 does not send/receive packets if not plugged in during boot X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Kurt Jaeger List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 20:10:07 -0000 The following reply was made to PR kern/148772; it has been noted by GNATS. From: Kurt Jaeger To: FreeBSD-gnats-submit@FreeBSD.org, freebsd-bugs@FreeBSD.org Cc: Subject: Re: kern/148772: alc0 does not send/receive packets if not plugged in during boot Date: Mon, 19 Jul 2010 22:05:23 +0200 Hi! > >Synopsis: alc0 does not send/receive packets if not plugged in during boot One thing: I can provide remote access to the system in question and to one beside it that shares the same ethernet. -- pi@opsec.eu +49 171 3101372 10 years to go ! From owner-freebsd-net@FreeBSD.ORG Tue Jul 20 14:41: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 C1AEE106564A for ; Tue, 20 Jul 2010 14:41:19 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5612C8FC19 for ; Tue, 20 Jul 2010 14:41:18 +0000 (UTC) Received: by ewy26 with SMTP id 26so1970638ewy.13 for ; Tue, 20 Jul 2010 07:41:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=NXdYBmMy/JuE1ZhM7UObIbxnPiXHLzFT0PuXkcNeEdQ=; b=PS6IJZrZ9Fr/kMLQ6KQujMQpbarhbJ6K3dQKpOT6+1HDQkBws5P25JiT3sL0VuoKlk DWkb+pOueTR9UizwAsUYWkSRm/51DLdDF/Cn1xTcwZ67WDNB08oiYd7e/mn0VDGR3WTe vRE7RZFreujsTtu67lx3kclIWlXyk0KsKyRMU= 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=Yo6//Aa6Laj10LiUuBiB2TQz5OpqAEe+Pjstl5BqGiRVArSD2//IvKx9G1aTKtw/nZ BuAQ3LwyUPHB0ILIG91ocHLh37BE87VHEbOl4cqr81fT9XpUohH32dBRW4/WwzQsc1Ee nt5rqtrHizxncor7X4n+TicmOwR4XR2t1qAUI= MIME-Version: 1.0 Received: by 10.213.114.67 with SMTP id d3mr3864216ebq.48.1279636878016; Tue, 20 Jul 2010 07:41:18 -0700 (PDT) Received: by 10.213.113.195 with HTTP; Tue, 20 Jul 2010 07:41:17 -0700 (PDT) In-Reply-To: <201007201030309214485@yahoo.com.cn> References: <201007191659457506137@yahoo.com.cn> <201007201030309214485@yahoo.com.cn> Date: Tue, 20 Jul 2010 10:41:17 -0400 Message-ID: From: Ryan Stone To: beezarliu Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net , Jack Vogel Subject: Re: Re: igb statistics error 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, 20 Jul 2010 14:41:19 -0000 The extra packets counted in tpr are packets received by the interface that were not addressed to that interface. The fact that your machine with a 82571 has not seen any such packets is just a coincidence. Whatever switch that machine is connected to has happened not to have flooded unicast packets to an unknown destination in the time that the machine has been up. From owner-freebsd-net@FreeBSD.ORG Tue Jul 20 19:54: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 7DFCB106566C for ; Tue, 20 Jul 2010 19:54:25 +0000 (UTC) (envelope-from pebu3op@googlemail.com) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [130.149.220.252]) by mx1.freebsd.org (Postfix) with ESMTP id 24BFB8FC17 for ; Tue, 20 Jul 2010 19:54:23 +0000 (UTC) Received: from raven.net.t-labs.tu-berlin.de (raven.net.t-labs.tu-berlin.de [130.149.220.18]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id 28D3F700C81C for ; Tue, 20 Jul 2010 21:54:23 +0200 (CEST) From: Alexander Fiveg Organization: Google To: freebsd-net@freebsd.org Date: Tue, 20 Jul 2010 21:54:18 +0200 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201007202154.19448.pebu3op@googlemail.com> Subject: support for L3/L4-filters in ixgbe X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pebu3op@googlemail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 19:54:25 -0000 Hello hackers, I have a couple of questions about the support of multiple-queues in the ixgbe driver. I am working on ringmap project in context of GSOC-2010. Currently I am trying to integrate ringmap with ixgbe. The network controller on my test-machine: 82599. My questions are: - Is there any interface to the user-space that allows the user-space process (for example by using ioctl()) to assign one specific queue for packets matched by L3/L4 filter (IP's , L4-protocols, ports). Has anyone tried to implement it for ixgbe? (If no, then I would try to implement this functionality and in this case any suggestions and advices would be very helpfull!) - Which filter can be used for assigning the network packets to a specific queue based on MAC-address ? (As far as I know it from datasheet, L2-filer matches only Ethertype, not the MAC-address-bytes. probably it can be done only by "flow director filter") Thanks, Alex P.S. Some outputs on my machine: % uname -v FreeBSD 9.0-CURRENT #1 % sysctl kern.osreldate kern.osreldate: 900014 % sysctl dev.ix.0 dev.ix.0.%desc: Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 2.2.3 dev.ix.0.%driver: ix dev.ix.0.%location: slot=0 function=0 dev.ix.0.%pnpinfo: vendor=0x8086 device=0x10fb subvendor=0x8086 subdevice=0x0003 class=0x020000 dev.ix.0.%parent: pci1 dev.ix.0.stats: -1 dev.ix.0.debug: -1 dev.ix.0.flow_control: 3 dev.ix.0.advertise_gig: 0 dev.ix.0.enable_aim: 1 dev.ix.0.rx_processing_limit: 128 % cat /var/log/messages | grep ix Jul 15 18:31:38 ringmap-2 kernel: ix0: port 0xac00-0xac1f mem 0xfe780000-0xfe7fffff,0xfe77c000-0xfe77ffff irq 16 at device 0.0 on pci1 Jul 15 18:31:38 ringmap-2 kernel: ix0: Using MSIX interrupts with 9 vectors Jul 15 18:31:38 ringmap-2 kernel: ix0: [ITHREAD] Jul 15 18:31:38 ringmap-2 kernel: ix0: Ethernet address: 00:1b:21:5a:67:70 Jul 15 18:31:38 ringmap-2 kernel: ix0: PCI Express Bus: Speed 2.5Gb/s Width x8 Jul 15 18:31:38 ringmap-2 kernel: ix1: port 0xa800-0xa81f mem 0xfe680000-0xfe6fffff,0xfe778000-0xfe77bfff irq 17 at device 0.1 on pci1 Jul 15 18:31:38 ringmap-2 kernel: ix1: Using MSIX interrupts with 9 vectors Jul 15 18:31:38 ringmap-2 kernel: ix1: RX Descriptors exceed system mbuf max, using default instead! Jul 15 18:31:38 ringmap-2 kernel: ix1: [ITHREAD] Jul 15 18:31:38 ringmap-2 kernel: ix1: Ethernet address: 00:1b:21:5a:67:71 Jul 15 18:31:38 ringmap-2 kernel: ix1: PCI Express Bus: Speed 2.5Gb/s Width x8 From owner-freebsd-net@FreeBSD.ORG Tue Jul 20 21:50:37 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 5F6631065674; Tue, 20 Jul 2010 21:50:37 +0000 (UTC) (envelope-from arundel@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 377628FC13; Tue, 20 Jul 2010 21:50:37 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o6KLobgm087400; Tue, 20 Jul 2010 21:50:37 GMT (envelope-from arundel@freefall.freebsd.org) Received: (from arundel@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o6KLobqn087396; Tue, 20 Jul 2010 21:50:37 GMT (envelope-from arundel) Date: Tue, 20 Jul 2010 21:50:37 GMT Message-Id: <201007202150.o6KLobqn087396@freefall.freebsd.org> To: arundel@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: arundel@FreeBSD.org Cc: Subject: Re: kern/148784: arp(8): arp pub not working properly 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, 20 Jul 2010 21:50:37 -0000 Old Synopsis: arp pub not working properly New Synopsis: arp(8): arp pub not working properly Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: arundel Responsible-Changed-When: Tue Jul 20 21:40:58 UTC 2010 Responsible-Changed-Why: Over to maintainer(s) http://www.freebsd.org/cgi/query-pr.cgi?pr=148784 From owner-freebsd-net@FreeBSD.ORG Tue Jul 20 21:55: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 9F0E11065670 for ; Tue, 20 Jul 2010 21:55:47 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 35A138FC1F for ; Tue, 20 Jul 2010 21:55:46 +0000 (UTC) Received: by ewy26 with SMTP id 26so2269222ewy.13 for ; Tue, 20 Jul 2010 14:55:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=vl7UZD20tVKUdjwqTUAmeq4eoaNuGrF2JcjzQ9Ag24w=; b=v1gTUK/G41vPIC6YH7sywEZ8D61Xmd/yHZ2y3mCBAcLADvt00BCEULR8CouK/UWQVj C8hZeUFkkRKkFQzHSIisAg8/kb68AeQF0HXb3RoJ1EF1XDoe4a1CJ657mndsUF0/x8X+ 8cas346tNsPvWBuYRw3g6y8JRFBmC+bYuO1To= 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=FENjOVc77t15/kkEi3pYT6j3hNNWra/ype5b+sgG7jNrnRKdMS6ZjfEdqtwZrwf4tu tTUuVlis4UA21qHWiZuWervcNVFEkZlV4K997XaJdLSCCmUlzElthkzXe51yeVG4hK1e +XyATPRK+RsJqOmfb3EEmFn6VkJzPW4PLWseQ= MIME-Version: 1.0 Received: by 10.213.7.65 with SMTP id c1mr5233963ebc.16.1279662946116; Tue, 20 Jul 2010 14:55:46 -0700 (PDT) Received: by 10.213.113.195 with HTTP; Tue, 20 Jul 2010 14:55:46 -0700 (PDT) In-Reply-To: <201007202154.19448.pebu3op@googlemail.com> References: <201007202154.19448.pebu3op@googlemail.com> Date: Tue, 20 Jul 2010 17:55:46 -0400 Message-ID: From: Ryan Stone To: pebu3op@googlemail.com Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org Subject: Re: support for L3/L4-filters in ixgbe 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, 20 Jul 2010 21:55:47 -0000 Currently there's interface for giving access to queues to userspace. One problem that you're going to run into is that the registers for all of the queues are mapped consecutively. There wouldn't be any way of preventing the application from messing around with queues that don't belong to it. Using the PCI SIG IOV mode would presumably prevent that, but I'm not at all familiar with what would be necessary to use IOV mode. Also if you don't enable a virtualization mode I think that your userspace queue could get other flows, not just those matching your filter, if those flows happen to hash to your queue. The 82599 supports up to 128 MAC address filters(I think that the one gets reserved for use by the manageability interface). The RAH and RAL registers are what you'll need to program. Note that these registers direct packets to *pools* of queues, not directly to queues. You'll also need to enable either VMDq mode or IOV mode to use pools 1-63; if you don't then any traffic that passes a filter that directs to a pool is implicitly directed to pool 0. I've done a lot of work on both the 82598 and the 82599 with VMDq mode to present multiple virtual interfaces to the kernel(the code, sadly, is not public). If you have any questions about the ixgbe driver or the virtualization features of the 82599 I'll be happy to offer any help I can. From owner-freebsd-net@FreeBSD.ORG Tue Jul 20 21:56: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 85F11106566C for ; Tue, 20 Jul 2010 21:56:47 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1A9488FC15 for ; Tue, 20 Jul 2010 21:56:46 +0000 (UTC) Received: by eyh6 with SMTP id 6so1701017eyh.13 for ; Tue, 20 Jul 2010 14:56:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=Sza6Y65Z49kaXiqPj9Z1UMaFkxXkA7+P5uB6YC384v0=; b=qdvaKmvzmpeYo/UjRp5diZZtRL9Bj6Hw69spaq7nyXfmu+70moJw9iY6vcnR1TS4Tu aUnt4DVqwq6A3hMs7oDUrQRdjHxMjRvnIR4DAY85af01+Rn5UGtigx2bxHLk8rUrcT7V 0EmACV5TInUq2DDwfGS667FJrUonCqG7vesz0= 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=VQGUu/3hLJCWK79TX+M+L/ddVyg0z3tmCbHt7nvzuXtj4uzZNNgWzxM0mOnJQt4YD3 0Eag1fu0reK/G2TiNafeo5nuV4qJ5tfIDn76GDiTdQx6QFV9y7zAgty57RBG4LbF+KAU XYPWa4s7SBhNSVmD6pN+3M5jeDVa864nDHMhs= MIME-Version: 1.0 Received: by 10.213.14.81 with SMTP id f17mr5399415eba.28.1279663006018; Tue, 20 Jul 2010 14:56:46 -0700 (PDT) Received: by 10.213.113.195 with HTTP; Tue, 20 Jul 2010 14:56:45 -0700 (PDT) In-Reply-To: References: <201007202154.19448.pebu3op@googlemail.com> Date: Tue, 20 Jul 2010 17:56:45 -0400 Message-ID: From: Ryan Stone To: pebu3op@googlemail.com Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org Subject: Re: support for L3/L4-filters in ixgbe 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, 20 Jul 2010 21:56:49 -0000 On Tue, Jul 20, 2010 at 5:55 PM, Ryan Stone wrote: > Currently there's interface for giving access to queues to userspace. That should of course read "Currently there's *no* interface..." From owner-freebsd-net@FreeBSD.ORG Tue Jul 20 22:15: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 031E9106564A for ; Tue, 20 Jul 2010 22:15:56 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id AB3CD8FC0A for ; Tue, 20 Jul 2010 22:15:55 +0000 (UTC) Received: by qyk30 with SMTP id 30so3146138qyk.13 for ; Tue, 20 Jul 2010 15:15:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=pY4NNof+DKR3vpNL6rHuJe9hO/rair9MxLS/6QHsGeU=; b=RDEljb74emE1shyWP117CWOWFTy9peHXjXapM1RA0tKsrPArDqS6sxz/qxaCDVmtwz RaL1O5eI/Q8yKbBcTeVnU2n6nNWpgAWtypSO8q/3YQRSWa/I9cScuWTJMvsu3vejHq8L US3jgQgWbNmbgxIEG5bENkkVbwYw5CVRycSUQ= 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=Uu206D9aL1JUGE1M5PYQ2RmjSWj7b3eKnTYML61LmDjBuo5Ykun9MGpItIcVMmSvIK lhDJ2yMTjld2M0lim6XnmRchk9m+TX9beC7V80ngGXZt9TlaDxtaupF9ZD7yDxWOQG8E Fvw5dSvGCkBOXFe7M8Gs2I5EFPayIevEPC/Wc= MIME-Version: 1.0 Received: by 10.224.37.78 with SMTP id w14mr4337398qad.75.1279664154697; Tue, 20 Jul 2010 15:15:54 -0700 (PDT) Received: by 10.229.26.15 with HTTP; Tue, 20 Jul 2010 15:15:54 -0700 (PDT) In-Reply-To: References: <201007202154.19448.pebu3op@googlemail.com> Date: Tue, 20 Jul 2010 15:15:54 -0700 Message-ID: From: Jack Vogel To: Ryan Stone Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, pebu3op@googlemail.com Subject: Re: support for L3/L4-filters in ixgbe 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, 20 Jul 2010 22:15:56 -0000 Am working on SR-IOV support in the driver now, of course at the moment its only to provide the VF (guest) side of things. To use a controlling/host IOV driver I need support in the PCI subsystem and perhaps elsewhere. If the infrastructure is there I'd be happy to add PF support. Jack On Tue, Jul 20, 2010 at 2:55 PM, Ryan Stone wrote: > Currently there's interface for giving access to queues to userspace. > One problem that you're going to run into is that the registers for > all of the queues are mapped consecutively. There wouldn't be any way > of preventing the application from messing around with queues that > don't belong to it. Using the PCI SIG IOV mode would presumably > prevent that, but I'm not at all familiar with what would be necessary > to use IOV mode. Also if you don't enable a virtualization mode I > think that your userspace queue could get other flows, not just those > matching your filter, if those flows happen to hash to your queue. > > The 82599 supports up to 128 MAC address filters(I think that the one > gets reserved for use by the manageability interface). The RAH and > RAL registers are what you'll need to program. Note that these > registers direct packets to *pools* of queues, not directly to queues. > You'll also need to enable either VMDq mode or IOV mode to use pools > 1-63; if you don't then any traffic that passes a filter that directs > to a pool is implicitly directed to pool 0. > > I've done a lot of work on both the 82598 and the 82599 with VMDq mode > to present multiple virtual interfaces to the kernel(the code, sadly, > is not public). If you have any questions about the ixgbe driver or > the virtualization features of the 82599 I'll be happy to offer any > help I can. > _______________________________________________ > 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 Jul 20 22:34:07 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 C24B2106566C; Tue, 20 Jul 2010 22:34:07 +0000 (UTC) (envelope-from yongari@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 997378FC16; Tue, 20 Jul 2010 22:34:07 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o6KMY7m9031119; Tue, 20 Jul 2010 22:34:07 GMT (envelope-from yongari@freefall.freebsd.org) Received: (from yongari@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o6KMY7oV031115; Tue, 20 Jul 2010 22:34:07 GMT (envelope-from yongari) Date: Tue, 20 Jul 2010 22:34:07 GMT Message-Id: <201007202234.o6KMY7oV031115@freefall.freebsd.org> To: fbsd-pr@opsec.eu, yongari@FreeBSD.org, freebsd-net@FreeBSD.org, yongari@FreeBSD.org From: yongari@FreeBSD.org Cc: Subject: Re: kern/148772: [alc] alc0 does not send/receive packets if not plugged in during boot 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, 20 Jul 2010 22:34:07 -0000 Synopsis: [alc] alc0 does not send/receive packets if not plugged in during boot State-Changed-From-To: open->feedback State-Changed-By: yongari State-Changed-When: Tue Jul 20 22:32:06 UTC 2010 State-Changed-Why: Would you try the patch at the following URL and let me know whether it makes any difference? http://people.freebsd.org/~yongari/alc/alc.link.patch Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Tue Jul 20 22:32:06 UTC 2010 Responsible-Changed-Why: Mine. http://www.freebsd.org/cgi/query-pr.cgi?pr=148772 From owner-freebsd-net@FreeBSD.ORG Wed Jul 21 00:21: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 DACD4106564A for ; Wed, 21 Jul 2010 00:21:38 +0000 (UTC) (envelope-from mahan@mahan.org) Received: from ns.mahan.org (ns.mahan.org [67.116.10.138]) by mx1.freebsd.org (Postfix) with ESMTP id 078368FC13 for ; Wed, 21 Jul 2010 00:21:37 +0000 (UTC) Received: from Gypsy.mahan.org (crowTrobot [67.116.10.140]) by ns.mahan.org (8.13.6/8.13.6) with ESMTP id o6L0Nh0J027809 for ; Tue, 20 Jul 2010 17:23:44 -0700 (PDT) (envelope-from mahan@mahan.org) Message-ID: <4C463D90.6040308@mahan.org> Date: Tue, 20 Jul 2010 17:21:36 -0700 From: Patrick Mahan User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Looking for some education on ALTQ 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, 21 Jul 2010 00:21:38 -0000 I am the first to admit I don't understand ALTQ and it's impact on QoS but that said, I am trying to learn. I have the following three systems. All systems are running FreeBSD 8.0-p2 Release. I am attempting to learn how AltQ can be used to prioritized and setup banddwith pipelines. At the end of this message is the topology and all (I hope) the relevent info for someone to help me understand what is happening. I have setup AltQ on em0 on NPX3 with a queue set to run at 1.9Mbps. However, in testing by generating UDP traffic on NPX4 and having it received on NPX3 I am seeing (what I believe) to be really low throughput scores for queue test7788 (see the pf.conf below). pfctl -vv -s queue shows the bandwidth starts at 4.84 Kb/s, not 1.9 Mbps I was expecting. Am I 1. Not driving the datastream high enough to eat 1.9 Mbps (what should I run as my iperf -b value? 2. Miss configuring AltQ? or 3. There is a bug in AltQ? Thanks for the education - Patrick Network topology: +--------------+ +--------------+ | | | | | NPX4 | | NPX3 | | (em1)+ ===================== +(em2) | | | | | | | | (em0) | +--------------+ +------+-------+ I I I I I I I I +------+-------+ | (em0) | | | | NPX1 | | | | | +--------------+ NPX4: em1: 172.16.34.40/24 em1: flags=8843 metric 0 mtu 1500 options=19b ether 00:1f:29:5f:c3:b8 inet 172.16.34.40 netmask 0xffffff00 broadcast 172.16.34.255 media: Ethernet autoselect (1000baseT ) status: active NPX3: em2: 172.16.34.30/24 em2: flags=8843 metric 0 mtu 1500 options=19b ether 00:1f:29:5f:c6:ab inet 172.16.34.30 netmask 0xffffff00 broadcast 172.16.34.255 media: Ethernet autoselect (1000baseT ) status: active em0: 172.16.13.30/24 em0: flags=8843 metric 0 mtu 1500 options=19b ether 00:1f:29:5f:c6:a9 inet 172.16.13.30 netmask 0xffffff00 broadcast 172.16.13.255 media: Ethernet autoselect (1000baseT ) status: active NPX1: em0: 172.16.13.10/24 em0: flags=8843 metric 0 mtu 1500 options=19b ether 00:1c:c4:47:1a:35 inet 172.16.13.10 netmask 0xffffff00 broadcast 172.16.13.255 media: Ethernet autoselect (1000baseT ) status: active NPX4 IPv4 Routing table npx4# netstat -nr Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 10.10.1.1 UG 0 248 bce0 10.10.0.0/16 link#5 U 4 1000928 bce0 10.10.20.44 link#5 UHS 0 296522 lo0 122.16.1.0/24 122.16.2.11 UGS 0 40392 em3 122.16.1.3 122.16.2.11 UGHS 0 251513 em3 122.16.2.0/24 122.16.2.3 U 0 3 em3 122.16.2.3 link#4 UHS 0 0 lo0 127.0.0.0/8 127.0.0.1 UR 0 0 lo0 127.0.0.1 link#8 UH 0 45442955 lo0 172.16.13.0/24 172.16.34.30 UGS 0 1754682 em1 172.16.24.0/24 172.16.24.40 U 0 7805039 em0 172.16.24.40 link#1 UHS 0 0 lo0 172.16.34.0/24 172.16.34.40 U 0 10425 em1 172.16.34.40 link#2 UHS 0 0 lo0 NPX3 IPv4 Routing Table npx3# netstat -nr Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 10.10.1.1 UG 0 0 bce0 10.10.0.0/16 link#5 U 5 21972 bce0 10.10.20.43 link#5 UHS 0 5113 lo0 127.0.0.0/8 127.0.0.1 UR 0 0 lo0 127.0.0.1 link#9 UH 0 310084 lo0 172.16.13.0/24 link#1 U 0 1754798 em0 172.16.13.30 link#1 UHS 0 0 lo0 172.16.23.0/24 link#2 U 0 138 em1 172.16.23.30 link#2 UHS 0 0 lo0 172.16.34.0/24 link#3 U 0 193 em2 172.16.34.30 link#3 UHS 0 0 lo0 172.16.38.0/24 link#4 U 0 142 em3 172.16.38.30 link#4 UHS 0 0 lo0 NPX1 IPv4 Routing Table npx1# netstat -nr Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 10.10.1.1 UG 0 4 bce0 10.10.0.0/16 link#5 U 6 8161 bce0 10.10.20.41 link#5 UHS 0 3434 lo0 127.0.0.0/8 127.0.0.1 UR 0 0 lo0 127.0.0.1 link#9 UH 0 40170 lo0 172.16.13.0/24 link#1 U 0 5946 em0 172.16.13.10 link#1 UHS 0 0 lo0 172.16.15.0/24 link#2 U 0 356728 em1 172.16.15.10 link#2 UHS 0 0 lo0 172.16.16.0/24 link#3 U 0 5945 em2 172.16.16.10 link#3 UHS 0 0 lo0 172.16.17.0/24 172.16.17.10 U 0 344560 em3 172.16.17.10 link#4 UHS 0 0 lo0 172.16.18.0/24 link#6 U 0 357350 bce1 172.16.18.10 link#6 UHS 0 0 lo0 172.16.34.0/24 172.16.13.30 UGS 0 2 em0 NPX3 has forwarding enabled npx3# sysctl net.inet.ip.forwarding net.inet.ip.forwarding: 1 NPX4 has a route to NPX1 via em1 172.16.13.0/24 172.16.34.30 UGS 0 1754682 em1 NPX1 has a route to NPX4 via em0 172.16.34.0/24 172.16.13.30 UGS 0 2 em0 On NPX3 the following /etc/pf.conf is enabled npx3# cat /etc/pf.conf ####################################################################### # ALT-Q Configuration ####################################################################### #====================================================================== # Cluster configuration #====================================================================== altq on em0 cbq bandwidth 1000Mb queue { test7788 } #====================================================================== # Queueu configuration #====================================================================== queue test7788 bandwidth 1900Kb priority 1 cbq (default) #====================================================================== # Filter rules #====================================================================== pass out quick on em3 inet proto udp from any to any port 7788 no state queue test7788 On NPX1 I start iperf in server mode npx1# iperf -s -p 7788 -u -i 30 ------------------------------------------------------------ Server listening on UDP port 7788 Receiving 1470 byte datagrams UDP buffer size: 41.1 KByte (default) ------------------------------------------------------------ [ 3] local 172.16.13.10 port 7788 connected with 172.16.34.40 port 44004 [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [ 3] 0.0-30.0 sec 89.5 MBytes 25.0 Mbits/sec 0.111 ms 0/63830 (0%) [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [ 3] 30.0-60.0 sec 89.5 MBytes 25.0 Mbits/sec 0.045 ms 0/63830 (0%) [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [ 3] 60.0-90.0 sec 89.5 MBytes 25.0 Mbits/sec 0.045 ms 0/63830 (0%) [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [ 3] 90.0-120.0 sec 89.5 MBytes 25.0 Mbits/sec 0.048 ms 0/63830 (0%) [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [ 3] 120.0-150.0 sec 89.5 MBytes 25.0 Mbits/sec 0.044 ms 0/63829 (0%) [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [ 3] 150.0-180.0 sec 89.5 MBytes 25.0 Mbits/sec 0.045 ms 0/63830 (0%) [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [ 3] 0.0-200.0 sec 597 MBytes 25.0 Mbits/sec 0.045 ms 0/425533 (0%) On NPX4 I start the iperf client npx4# iperf -c 172.16.13.10 -p 7788 -u -b 25M -u -i 30 -t 200 ------------------------------------------------------------ Client connecting to 172.16.13.10, UDP port 7788 Sending 1470 byte datagrams UDP buffer size: 9.00 KByte (default) ------------------------------------------------------------ [ 3] local 172.16.34.40 port 44004 connected with 172.16.13.10 port 7788 [ ID] Interval Transfer Bandwidth [ 3] 0.0-30.0 sec 89.5 MBytes 25.0 Mbits/sec [ ID] Interval Transfer Bandwidth [ 3] 30.0-60.0 sec 89.5 MBytes 25.0 Mbits/sec [ ID] Interval Transfer Bandwidth [ 3] 60.0-90.0 sec 89.5 MBytes 25.0 Mbits/sec [ ID] Interval Transfer Bandwidth [ 3] 90.0-120.0 sec 89.5 MBytes 25.0 Mbits/sec [ ID] Interval Transfer Bandwidth [ 3] 120.0-150.0 sec 89.5 MBytes 25.0 Mbits/sec [ ID] Interval Transfer Bandwidth [ 3] 150.0-180.0 sec 89.5 MBytes 25.0 Mbits/sec [ ID] Interval Transfer Bandwidth [ 3] 0.0-200.0 sec 597 MBytes 25.0 Mbits/sec [ 3] Sent 425533 datagrams [ 3] Server Report: [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [ 3] 0.0-200.0 sec 597 MBytes 25.0 Mbits/sec 0.044 ms 0/425533 (0%) On NPX3 I start monitoring of the Altq npx3: pfctl -vv -s queue queue root_em0 on em0 bandwidth 1Gb priority 0 cbq( wrr root ) {test7788} [ pkts: 75 bytes: 113400 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] queue test7788 on em0 bandwidth 1.90Mb cbq( default ) [ pkts: 75 bytes: 113400 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] queue root_em0 on em0 bandwidth 1Gb priority 0 cbq( wrr root ) {test7788} [ pkts: 77 bytes: 116424 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.4 packets/s, 4.84Kb/s ] queue test7788 on em0 bandwidth 1.90Mb cbq( default ) [ pkts: 77 bytes: 116424 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.4 packets/s, 4.84Kb/s ] queue root_em0 on em0 bandwidth 1Gb priority 0 cbq( wrr root ) {test7788} [ pkts: 77 bytes: 116424 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.2 packets/s, 2.42Kb/s ] queue test7788 on em0 bandwidth 1.90Mb cbq( default ) [ pkts: 77 bytes: 116424 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.2 packets/s, 2.42Kb/s ] queue root_em0 on em0 bandwidth 1Gb priority 0 cbq( wrr root ) {test7788} [ pkts: 77 bytes: 116424 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.1 packets/s, 1.61Kb/s ] queue test7788 on em0 bandwidth 1.90Mb cbq( default ) [ pkts: 77 bytes: 116424 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.1 packets/s, 1.61Kb/s ] queue root_em0 on em0 bandwidth 1Gb priority 0 cbq( wrr root ) {test7788} [ pkts: 77 bytes: 116424 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.1 packets/s, 1.21Kb/s ] queue test7788 on em0 bandwidth 1.90Mb cbq( default ) [ pkts: 77 bytes: 116424 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.1 packets/s, 1.21Kb/s ] queue root_em0 on em0 bandwidth 1Gb priority 0 cbq( wrr root ) {test7788} [ pkts: 77 bytes: 116424 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.1 packets/s, 967.68 b/s ] queue test7788 on em0 bandwidth 1.90Mb cbq( default ) [ pkts: 77 bytes: 116424 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.1 packets/s, 967.68 b/s ] queue root_em0 on em0 bandwidth 1Gb priority 0 cbq( wrr root ) {test7788} [ pkts: 77 bytes: 116424 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.1 packets/s, 806.40 b/s ] queue test7788 on em0 bandwidth 1.90Mb cbq( default ) [ pkts: 77 bytes: 116424 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.1 packets/s, 806.40 b/s ] queue root_em0 on em0 bandwidth 1Gb priority 0 cbq( wrr root ) {test7788} [ pkts: 77 bytes: 116424 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.1 packets/s, 691.20 b/s ] queue test7788 on em0 bandwidth 1.90Mb cbq( default ) [ pkts: 77 bytes: 116424 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.1 packets/s, 691.20 b/s ] queue root_em0 on em0 bandwidth 1Gb priority 0 cbq( wrr root ) {test7788} [ pkts: 84 bytes: 127008 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.2 packets/s, 2.72Kb/s ] queue test7788 on em0 bandwidth 1.90Mb cbq( default ) [ pkts: 84 bytes: 127008 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.2 packets/s, 2.72Kb/s ] queue root_em0 on em0 bandwidth 1Gb priority 0 cbq( wrr root ) {test7788} [ pkts: 84 bytes: 127008 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.2 packets/s, 2.38Kb/s ] queue test7788 on em0 bandwidth 1.90Mb cbq( default ) [ pkts: 84 bytes: 127008 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.2 packets/s, 2.38Kb/s ] queue root_em0 on em0 bandwidth 1Gb priority 0 cbq( wrr root ) {test7788} [ pkts: 84 bytes: 127008 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.2 packets/s, 2.08Kb/s ] queue test7788 on em0 bandwidth 1.90Mb cbq( default ) [ pkts: 84 bytes: 127008 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.2 packets/s, 2.08Kb/s ] queue root_em0 on em0 bandwidth 1Gb priority 0 cbq( wrr root ) {test7788} [ pkts: 84 bytes: 127008 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.2 packets/s, 1.82Kb/s ] queue test7788 on em0 bandwidth 1.90Mb cbq( default ) [ pkts: 84 bytes: 127008 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.2 packets/s, 1.82Kb/s ] queue root_em0 on em0 bandwidth 1Gb priority 0 cbq( wrr root ) {test7788} [ pkts: 84 bytes: 127008 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.1 packets/s, 1.60Kb/s ] queue test7788 on em0 bandwidth 1.90Mb cbq( default ) [ pkts: 84 bytes: 127008 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.1 packets/s, 1.60Kb/s ] queue root_em0 on em0 bandwidth 1Gb priority 0 cbq( wrr root ) {test7788} [ pkts: 84 bytes: 127008 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.1 packets/s, 1.40Kb/s ] queue test7788 on em0 bandwidth 1.90Mb cbq( default ) [ pkts: 84 bytes: 127008 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.1 packets/s, 1.40Kb/s ] queue root_em0 on em0 bandwidth 1Gb priority 0 cbq( wrr root ) {test7788} [ pkts: 84 bytes: 127008 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.1 packets/s, 1.22Kb/s ] queue test7788 on em0 bandwidth 1.90Mb cbq( default ) [ pkts: 84 bytes: 127008 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.1 packets/s, 1.22Kb/s ] queue root_em0 on em0 bandwidth 1Gb priority 0 cbq( wrr root ) {test7788} [ pkts: 86 bytes: 130032 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.1 packets/s, 1.67Kb/s ] queue test7788 on em0 bandwidth 1.90Mb cbq( default ) [ pkts: 86 bytes: 130032 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.1 packets/s, 1.67Kb/s ] queue root_em0 on em0 bandwidth 1Gb priority 0 cbq( wrr root ) {test7788} [ pkts: 88 bytes: 133056 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.2 packets/s, 2.07Kb/s ] queue test7788 on em0 bandwidth 1.90Mb cbq( default ) [ pkts: 88 bytes: 133056 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.2 packets/s, 2.07Kb/s ] queue root_em0 on em0 bandwidth 1Gb priority 0 cbq( wrr root ) {test7788} [ pkts: 88 bytes: 133056 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.1 packets/s, 1.81Kb/s ] queue test7788 on em0 bandwidth 1.90Mb cbq( default ) [ pkts: 88 bytes: 133056 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.1 packets/s, 1.81Kb/s ] queue root_em0 on em0 bandwidth 1Gb priority 0 cbq( wrr root ) {test7788} [ pkts: 88 bytes: 133056 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.1 packets/s, 1.58Kb/s ] queue test7788 on em0 bandwidth 1.90Mb cbq( default ) [ pkts: 88 bytes: 133056 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.1 packets/s, 1.58Kb/s ] queue root_em0 on em0 bandwidth 1Gb priority 0 cbq( wrr root ) {test7788} [ pkts: 88 bytes: 133056 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.1 packets/s, 1.39Kb/s ] queue test7788 on em0 bandwidth 1.90Mb cbq( default ) [ pkts: 88 bytes: 133056 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.1 packets/s, 1.39Kb/s ] queue root_em0 on em0 bandwidth 1Gb priority 0 cbq( wrr root ) {test7788} [ pkts: 88 bytes: 133056 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.1 packets/s, 1.21Kb/s ] queue test7788 on em0 bandwidth 1.90Mb cbq( default ) [ pkts: 88 bytes: 133056 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.1 packets/s, 1.21Kb/s ] queue root_em0 on em0 bandwidth 1Gb priority 0 cbq( wrr root ) {test7788} [ pkts: 90 bytes: 136080 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.1 packets/s, 1.67Kb/s ] queue test7788 on em0 bandwidth 1.90Mb cbq( default ) [ pkts: 90 bytes: 136080 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.1 packets/s, 1.67Kb/s ] queue root_em0 on em0 bandwidth 1Gb priority 0 cbq( wrr root ) {test7788} [ pkts: 90 bytes: 136080 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.1 packets/s, 1.46Kb/s ] queue test7788 on em0 bandwidth 1.90Mb cbq( default ) [ pkts: 90 bytes: 136080 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.1 packets/s, 1.46Kb/s ] queue root_em0 on em0 bandwidth 1Gb priority 0 cbq( wrr root ) {test7788} [ pkts: 90 bytes: 136080 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.1 packets/s, 1.28Kb/s ] queue test7788 on em0 bandwidth 1.90Mb cbq( default ) [ pkts: 90 bytes: 136080 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.1 packets/s, 1.28Kb/s ] queue root_em0 on em0 bandwidth 1Gb priority 0 cbq( wrr root ) {test7788} [ pkts: 90 bytes: 136080 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.1 packets/s, 1.12Kb/s ] queue test7788 on em0 bandwidth 1.90Mb cbq( default ) [ pkts: 90 bytes: 136080 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.1 packets/s, 1.12Kb/s ] queue root_em0 on em0 bandwidth 1Gb priority 0 cbq( wrr root ) {test7788} [ pkts: 90 bytes: 136080 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.1 packets/s, 976.63 b/s ] queue test7788 on em0 bandwidth 1.90Mb cbq( default ) [ pkts: 90 bytes: 136080 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.1 packets/s, 976.63 b/s ] queue root_em0 on em0 bandwidth 1Gb priority 0 cbq( wrr root ) {test7788} [ pkts: 90 bytes: 136080 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.1 packets/s, 854.55 b/s ] queue test7788 on em0 bandwidth 1.90Mb cbq( default ) [ pkts: 90 bytes: 136080 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.1 packets/s, 854.55 b/s ] queue root_em0 on em0 bandwidth 1Gb priority 0 cbq( wrr root ) {test7788} [ pkts: 90 bytes: 136080 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.1 packets/s, 747.74 b/s ] queue test7788 on em0 bandwidth 1.90Mb cbq( default ) [ pkts: 90 bytes: 136080 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.1 packets/s, 747.74 b/s ] queue root_em0 on em0 bandwidth 1Gb priority 0 cbq( wrr root ) {test7788} [ pkts: 98 bytes: 148176 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.3 packets/s, 3.07Kb/s ] queue test7788 on em0 bandwidth 1.90Mb cbq( default ) [ pkts: 98 bytes: 148176 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.3 packets/s, 3.07Kb/s ] queue root_em0 on em0 bandwidth 1Gb priority 0 cbq( wrr root ) {test7788} [ pkts: 100 bytes: 151200 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.3 packets/s, 3.29Kb/s ] queue test7788 on em0 bandwidth 1.90Mb cbq( default ) [ pkts: 100 bytes: 151200 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.3 packets/s, 3.29Kb/s ] queue root_em0 on em0 bandwidth 1Gb priority 0 cbq( wrr root ) {test7788} [ pkts: 100 bytes: 151200 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.2 packets/s, 2.88Kb/s ] queue test7788 on em0 bandwidth 1.90Mb cbq( default ) [ pkts: 100 bytes: 151200 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.2 packets/s, 2.88Kb/s ] queue root_em0 on em0 bandwidth 1Gb priority 0 cbq( wrr root ) {test7788} [ pkts: 100 bytes: 151200 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.2 packets/s, 2.52Kb/s ] queue test7788 on em0 bandwidth 1.90Mb cbq( default ) [ pkts: 100 bytes: 151200 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.2 packets/s, 2.52Kb/s ] queue root_em0 on em0 bandwidth 1Gb priority 0 cbq( wrr root ) {test7788} [ pkts: 102 bytes: 154224 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.2 packets/s, 2.81Kb/s ] queue test7788 on em0 bandwidth 1.90Mb cbq( default ) [ pkts: 102 bytes: 154224 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.2 packets/s, 2.81Kb/s ] queue root_em0 on em0 bandwidth 1Gb priority 0 cbq( wrr root ) {test7788} [ pkts: 102 bytes: 154224 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.2 packets/s, 2.46Kb/s ] queue test7788 on em0 bandwidth 1.90Mb cbq( default ) [ pkts: 102 bytes: 154224 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.2 packets/s, 2.46Kb/s ] queue root_em0 on em0 bandwidth 1Gb priority 0 cbq( wrr root ) {test7788} [ pkts: 102 bytes: 154224 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.2 packets/s, 2.15Kb/s ] queue test7788 on em0 bandwidth 1.90Mb cbq( default ) [ pkts: 102 bytes: 154224 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.2 packets/s, 2.15Kb/s ] queue root_em0 on em0 bandwidth 1Gb priority 0 cbq( wrr root ) {test7788} [ pkts: 104 bytes: 157248 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.2 packets/s, 2.49Kb/s ] queue test7788 on em0 bandwidth 1.90Mb cbq( default ) [ pkts: 104 bytes: 157248 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.2 packets/s, 2.49Kb/s ] queue root_em0 on em0 bandwidth 1Gb priority 0 cbq( wrr root ) {test7788} [ pkts: 104 bytes: 157248 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.2 packets/s, 2.18Kb/s ] queue test7788 on em0 bandwidth 1.90Mb cbq( default ) [ pkts: 104 bytes: 157248 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.2 packets/s, 2.18Kb/s ] queue root_em0 on em0 bandwidth 1Gb priority 0 cbq( wrr root ) {test7788} [ pkts: 104 bytes: 157248 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.2 packets/s, 1.91Kb/s ] queue test7788 on em0 bandwidth 1.90Mb cbq( default ) [ pkts: 104 bytes: 157248 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.2 packets/s, 1.91Kb/s ] queue root_em0 on em0 bandwidth 1Gb priority 0 cbq( wrr root ) {test7788} [ pkts: 106 bytes: 160272 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.2 packets/s, 2.27Kb/s ] queue test7788 on em0 bandwidth 1.90Mb cbq( default ) [ pkts: 106 bytes: 160272 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.2 packets/s, 2.27Kb/s ] queue root_em0 on em0 bandwidth 1Gb priority 0 cbq( wrr root ) {test7788} [ pkts: 106 bytes: 160272 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.2 packets/s, 1.99Kb/s ] queue test7788 on em0 bandwidth 1.90Mb cbq( default ) [ pkts: 106 bytes: 160272 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.2 packets/s, 1.99Kb/s ] queue root_em0 on em0 bandwidth 1Gb priority 0 cbq( wrr root ) {test7788} [ pkts: 106 bytes: 160272 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.1 packets/s, 1.74Kb/s ] queue test7788 on em0 bandwidth 1.90Mb cbq( default ) [ pkts: 106 bytes: 160272 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.1 packets/s, 1.74Kb/s ] queue root_em0 on em0 bandwidth 1Gb priority 0 cbq( wrr root ) {test7788} [ pkts: 106 bytes: 160272 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.1 packets/s, 1.52Kb/s ] queue test7788 on em0 bandwidth 1.90Mb cbq( default ) [ pkts: 106 bytes: 160272 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.1 packets/s, 1.52Kb/s ] queue root_em0 on em0 bandwidth 1Gb priority 0 cbq( wrr root ) {test7788} [ pkts: 106 bytes: 160272 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.1 packets/s, 1.33Kb/s ] queue test7788 on em0 bandwidth 1.90Mb cbq( default ) [ pkts: 106 bytes: 160272 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 borrows: 0 suspends: 0 ] [ measured: 0.1 packets/s, 1.33Kb/s ] From owner-freebsd-net@FreeBSD.ORG Wed Jul 21 06:29: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 A933E106567A; Wed, 21 Jul 2010 06:29:49 +0000 (UTC) (envelope-from pi@opsec.eu) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) by mx1.freebsd.org (Postfix) with ESMTP id 6174F8FC18; Wed, 21 Jul 2010 06:29:49 +0000 (UTC) Received: from pi by home.opsec.eu with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ObSoL-000NNY-5l; Wed, 21 Jul 2010 08:29:45 +0200 Date: Wed, 21 Jul 2010 08:29:45 +0200 From: Kurt Jaeger To: yongari@FreeBSD.org Message-ID: <20100721062945.GA51934@home.opsec.eu> References: <201007202234.o6KMY7oV031115@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201007202234.o6KMY7oV031115@freefall.freebsd.org> Cc: fbsd-pr@opsec.eu, freebsd-net@FreeBSD.org Subject: Re: kern/148772: [alc] alc0 does not send/receive packets if not plugged in during boot 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, 21 Jul 2010 06:29:49 -0000 Hi! > State-Changed-Why: > Would you try the patch at the following URL and let me know > whether it makes any difference? > http://people.freebsd.org/~yongari/alc/alc.link.patch The system hanged @boot with this entry in /etc/rc.conf: ifconfig_alc0="inet 192.168.5.10 netmask 255.255.255.0" After rebooting single-user, the system came up. alc0: flags=8802 metric 0 mtu 1500 options=c3198 ether 48:5b:39:73:03:4f media: Ethernet autoselect I was able to set an IP, but I was not able to use the interface. A shutdown hung(!), dead. A reboot with connected cable follows this evening. -- pi@opsec.eu +49 171 3101372 10 years to go ! From owner-freebsd-net@FreeBSD.ORG Wed Jul 21 06:32: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 0EC2D1065705; Wed, 21 Jul 2010 06:32:37 +0000 (UTC) (envelope-from pi@opsec.eu) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) by mx1.freebsd.org (Postfix) with ESMTP id BCAE68FC1E; Wed, 21 Jul 2010 06:32:36 +0000 (UTC) Received: from pi by home.opsec.eu with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ObSr4-000NRb-AY; Wed, 21 Jul 2010 08:32:34 +0200 Date: Wed, 21 Jul 2010 08:32:34 +0200 From: Kurt Jaeger To: yongari@FreeBSD.org Message-ID: <20100721063234.GB51934@home.opsec.eu> References: <201007202234.o6KMY7oV031115@freefall.freebsd.org> <20100721062945.GA51934@home.opsec.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100721062945.GA51934@home.opsec.eu> Cc: fbsd-pr@opsec.eu, freebsd-net@FreeBSD.org Subject: Re: kern/148772: [alc] alc0 does not send/receive packets if not plugged in during boot 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, 21 Jul 2010 06:32:37 -0000 Hi! > A reboot with connected cable follows this evening. A reboot with connected cable was booting successfully. -- pi@opsec.eu +49 171 3101372 10 years to go ! From owner-freebsd-net@FreeBSD.ORG Wed Jul 21 06:21: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 63FEA1065674 for ; Wed, 21 Jul 2010 06:21:59 +0000 (UTC) (envelope-from beezarliu@yahoo.com.cn) Received: from n16.bullet.mail.mud.yahoo.com (n16.bullet.mail.mud.yahoo.com [68.142.206.43]) by mx1.freebsd.org (Postfix) with SMTP id 1FFBA8FC1D for ; Wed, 21 Jul 2010 06:21:58 +0000 (UTC) Received: from [209.191.108.96] by n16.bullet.mail.mud.yahoo.com with NNFMP; 21 Jul 2010 06:21:58 -0000 Received: from [68.142.201.244] by t3.bullet.mud.yahoo.com with NNFMP; 21 Jul 2010 06:21:58 -0000 Received: from [127.0.0.1] by omp405.mail.mud.yahoo.com with NNFMP; 21 Jul 2010 06:21:58 -0000 X-Yahoo-Newman-Id: 506175.90058.bm@omp405.mail.mud.yahoo.com Received: (qmail 58834 invoked from network); 21 Jul 2010 06:21:57 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.cn; h=DKIM-Signature:Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Date:From:To:Cc:References:Subject:Message-ID:X-mailer:Mime-Version:Content-Type; b=b46EkwAW6KFsI8ydbfbepS1bj7oZrK3kEYFVDK8dbWGL41KBTvtkOzwD2ZZ7lHVtjGN9WPzSxVniV7U5DLmxnhjhoSqbdTZNuJ4qVCtjNqDpK18cvrOa6y+pkw7JQayIPmWzba3tu+S6swpAB1OK+yCQca7mEBND2RRFoLLp17A= ; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.cn; s=s1024; t=1279693317; bh=P1q/BpqJzz6irS202bpizUXmtNG1mdzXqoaEy72OIQs=; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Date:From:To:Cc:References:Subject:Message-ID:X-mailer:Mime-Version:Content-Type; b=fghIBAPjHNyg+tbjSzRIhORlFfE1hpflvRM9A3nNkAYmR18cLt5tD6cVWiRTJeLe0vuOTIJiHWmHUi9MH86tycJNkS/HQvS3fBAugObHvme5wdix9j3OGWLYMFmIYfoB7q4mZft4Zewl6iV5Bg6Dl/nEsbKbRIRQx0kod9kvdb0= Received: from PC-200811131239 (beezarliu@124.207.251.123 with login) by smtp113.plus.mail.sp1.yahoo.com with SMTP; 20 Jul 2010 23:21:56 -0700 PDT X-Yahoo-SMTP: YP5UPy2swBBHZGZlvbmOrntlD3fotw-- X-YMail-OSG: EhiBMNEVM1kttNg8vSadnohau_t4JFIgdYuPBmyTdG0yurL NwASBW2UZVTEyxgmsOF5abn2cTkqrpYWlAaHOfruu82YkxrY860hdd33Wq.p OsnKbbzR5J9bvQyh8J1V5ErJaPPt8xD7fJIXoeabpfqGADluJfSYRsv66kAn k86oCqdZOfZkOO5Usf5zIUoRwJjckVptTq7DuyqZyVRyqThzGo0v9_St6MvM kkbnkp8J_ygG0vLVEGOwoCnzPblE4 X-Yahoo-Newman-Property: ymail-3 Date: Wed, 21 Jul 2010 14:21:51 +0800 From: "beezarliu" To: "Ryan Stone" References: <201007191659457506137@yahoo.com.cn>, , <201007201030309214485@yahoo.com.cn>, Message-ID: <201007211421450467696@yahoo.com.cn> X-mailer: Foxmail 6, 10, 201, 20 [cn] Mime-Version: 1.0 X-Mailman-Approved-At: Wed, 21 Jul 2010 11:07:06 +0000 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net , Jack Vogel Subject: Re: Re: Re: igb statistics error 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, 21 Jul 2010 06:21:59 -0000 SXQncyBoYXJkIHRvIGJlbGlldmUgaXQncyBzd2l0Y2gncyBwcm9ibGVtIG9yIHVuaWNhc3QgaXNz dWUsIA0KYmVjYXVzZSBhbGwgdGhlIDgyNTc2LzgyNTcxIE5JQ3MgYXJlIG9uIHRoZSBzYW1lIHN3 aXRjaC4NCg0KSSBldmVuIGhhdmUgZG9uZSBhIHRlc3RpbmcuDQpJIHB1dCBvbmUgODI1NzEgYW5k IG9uZSA4MjU3NiBjYXJkIGluIHRoZSBzYW1lIG1hY2hpbmUuIEFuZCBhbGwgb2YgdGhlDQpOSUNz IGFyZSBwbHVnZ2VkIGludG8gYSBzYW1lIHN3aXRjaC4gQW5kIHRoZXkgYXJlIG5vdCBjb25maWd1 ZWQNCmFueSBJUCBhZGRyZXNzLCB0byBleGNsdWRlIHRoZSB1bmljYXN0IGlzc3VlLiAgDQpBbmQg SSBmb3VuZCB0aGUgc2FtZSByZXN1bHQuDQo4MjU3NidzIHRwciA+IDgyNTc4J3MgZ3ByYyA9IDgy NTcxJ3MgdHByID0gODI1NzEncyBncHJjLg0KDQpTbyBJJ20gcmVhbGx5IGN1cmlvdXMgYWJvdXQg dGhlIFRQUi4gSXMgdGhlIG1lYW5pbmcvaW1wbGVtZW50YXRpb24NCmNoYW5nZWQgZm9yIDgyNTc2 PyANCg0KVGhhbmtzDQoyMDEwLTA3LTIxIA0KDQoNCg0KYmVlemFybGl1IA0KDQoNCg0Kt6K8/sjL o7ogUnlhbiBTdG9uZSANCreiy83Ksbzko7ogMjAxMC0wNy0yMCAgMjI6NDE6MjAgDQrK1bz+yMuj uiBiZWV6YXJsaXUgDQqzrcvNo7ogZnJlZWJzZC1uZXQ7IEphY2sgVm9nZWwgDQrW98zio7ogUmU6 IFJlOiBpZ2Igc3RhdGlzdGljcyBlcnJvciANCiANClRoZSBleHRyYSBwYWNrZXRzIGNvdW50ZWQg aW4gdHByIGFyZSBwYWNrZXRzIHJlY2VpdmVkIGJ5IHRoZSBpbnRlcmZhY2UNCnRoYXQgd2VyZSBu b3QgYWRkcmVzc2VkIHRvIHRoYXQgaW50ZXJmYWNlLiAgVGhlIGZhY3QgdGhhdCB5b3VyIG1hY2hp bmUNCndpdGggYSA4MjU3MSBoYXMgbm90IHNlZW4gYW55IHN1Y2ggcGFja2V0cyBpcyBqdXN0IGEg Y29pbmNpZGVuY2UuDQpXaGF0ZXZlciBzd2l0Y2ggdGhhdCBtYWNoaW5lIGlzIGNvbm5lY3RlZCB0 byBoYXMgaGFwcGVuZWQgbm90IHRvIGhhdmUNCmZsb29kZWQgdW5pY2FzdCBwYWNrZXRzIHRvIGFu IHVua25vd24gZGVzdGluYXRpb24gaW4gdGhlIHRpbWUgdGhhdCB0aGUNCm1hY2hpbmUgaGFzIGJl ZW4gdXAuDQo= From owner-freebsd-net@FreeBSD.ORG Wed Jul 21 11:44:01 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 AD059106567F for ; Wed, 21 Jul 2010 11:44:01 +0000 (UTC) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (106-30.3-213.fix.bluewin.ch [213.3.30.106]) by mx1.freebsd.org (Postfix) with ESMTP id 0A4BF8FC13 for ; Wed, 21 Jul 2010 11:43:59 +0000 (UTC) Received: from insomnia.benzedrine.cx (localhost.benzedrine.cx [127.0.0.1]) by insomnia.benzedrine.cx (8.14.1/8.13.4) with ESMTP id o6LBhwYd022657 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Wed, 21 Jul 2010 13:43:58 +0200 (MEST) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.14.1/8.12.10/Submit) id o6LBhuKm032193; Wed, 21 Jul 2010 13:43:56 +0200 (MEST) Date: Wed, 21 Jul 2010 13:43:56 +0200 From: Daniel Hartmeier To: Patrick Mahan Message-ID: <20100721114356.GA9247@insomnia.benzedrine.cx> References: <4C463D90.6040308@mahan.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C463D90.6040308@mahan.org> User-Agent: Mutt/1.5.12-2006-07-14 Cc: freebsd-net@freebsd.org Subject: Re: Looking for some education on ALTQ 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, 21 Jul 2010 11:44:01 -0000 In your setup, the data is flowing from the iperf client (sender) on NPX4 to the iperf server (receiver) on NPX1. Apply the queue on the interface on NPX3 where the data is flowing out, i.e. the interface facing NPX1. Queueing applies to outgoing packets of an interface, not incoming packets. It looks like you confused the interface, according to the drawing the interface would be em0, but the ifconfig output places em0 in the network towards NPX4. Then the pass rule in pf.conf uses em3. It looks like you limited the (nearly non-existant) return traffic instead. When fixed, pfctl -vvsq should show quickly growing pkts and bytes counters for test7788, of the order iperf reports (133KB vs. 597MB in your output). Kind regards, Daniel From owner-freebsd-net@FreeBSD.ORG Wed Jul 21 12:50: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 0B39E1065670 for ; Wed, 21 Jul 2010 12:50:59 +0000 (UTC) (envelope-from freebsd-net@pp.dyndns.biz) Received: from smtprelay-h22.telenor.se (smtprelay-h22.telenor.se [195.54.99.197]) by mx1.freebsd.org (Postfix) with ESMTP id B63308FC1A for ; Wed, 21 Jul 2010 12:50:58 +0000 (UTC) Received: from ipb1.telenor.se (ipb1.telenor.se [195.54.127.164]) by smtprelay-h22.telenor.se (Postfix) with ESMTP id 38D56E9519 for ; Wed, 21 Jul 2010 14:24:14 +0200 (CEST) X-SENDER-IP: [85.226.59.55] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgczAIODRkxV4js3PGdsb2JhbACTM4w7DAEBAQE1Lb9yhTIE X-IronPort-AV: E=Sophos;i="4.55,238,1278280800"; d="scan'208";a="108570729" Received: from c-373be255.107-1-64736c10.cust.bredbandsbolaget.se (HELO gatekeeper.pp.dyndns.biz) ([85.226.59.55]) by ipb1.telenor.se with ESMTP; 21 Jul 2010 14:24:14 +0200 Received: from [192.168.69.67] (phobos [192.168.69.67]) by gatekeeper.pp.dyndns.biz (8.14.4/8.14.4) with ESMTP id o6LCODxd059192 for ; Wed, 21 Jul 2010 14:24:13 +0200 (CEST) (envelope-from freebsd-net@pp.dyndns.biz) Message-ID: <4C46E6ED.7010805@pp.dyndns.biz> Date: Wed, 21 Jul 2010 14:24:13 +0200 From: =?ISO-8859-1?Q?Morgan_Wesstr=F6m?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.10) Gecko/20100624 Lightning/1.0b1 Thunderbird/3.0.5 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <4C463D90.6040308@mahan.org> In-Reply-To: <4C463D90.6040308@mahan.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: Looking for some education on ALTQ 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, 21 Jul 2010 12:50:59 -0000 On 2010-07-21 02:21, Patrick Mahan wrote: > I am the first to admit I don't understand ALTQ and it's impact on QoS but > that said, I am trying to learn. > > I have the following three systems. All systems are running FreeBSD > 8.0-p2 Release. > I am attempting to learn how AltQ can be used to prioritized and setup > banddwith > pipelines. > > At the end of this message is the topology and all (I hope) the relevent > info for > someone to help me understand what is happening. > > I have setup AltQ on em0 on NPX3 with a queue set to run at 1.9Mbps. > However, in > testing by generating UDP traffic on NPX4 and having it received on NPX3 > I am > seeing (what I believe) to be really low throughput scores for queue > test7788 > (see the pf.conf below). > > pfctl -vv -s queue shows the bandwidth starts at 4.84 Kb/s, not 1.9 Mbps > I was > expecting. > > Am I > > 1. Not driving the datastream high enough to eat 1.9 Mbps (what should I > run as > my iperf -b value? > > 2. Miss configuring AltQ? > > or > > 3. There is a bug in AltQ? > > Thanks for the education - > > Patrick > > > Network topology: > According to the following PR, ALTQ doesn't work with em(4) in 8.0-p2. A patch has been submitted for later versions but since I haven't upgraded myself because of this issue, I'm not sure exactly what version you need. http://www.freebsd.org/cgi/query-pr.cgi?pr=138392 Regards Morgan From owner-freebsd-net@FreeBSD.ORG Wed Jul 21 16:30:56 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 88525106564A; Wed, 21 Jul 2010 16:30:56 +0000 (UTC) (envelope-from brucec@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 5EFF78FC08; Wed, 21 Jul 2010 16:30:56 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o6LGUuXJ016471; Wed, 21 Jul 2010 16:30:56 GMT (envelope-from brucec@freefall.freebsd.org) Received: (from brucec@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o6LGUu8N016459; Wed, 21 Jul 2010 16:30:56 GMT (envelope-from brucec) Date: Wed, 21 Jul 2010 16:30:56 GMT Message-Id: <201007211630.o6LGUu8N016459@freefall.freebsd.org> To: brucec@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: brucec@FreeBSD.org Cc: Subject: Re: kern/148807: [panic] 8.1-RELEASE "panic: sbdrop" and "panic: sbsndptr: sockbuf _ and mbuf _ clashing" under heavy load 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, 21 Jul 2010 16:30:56 -0000 Synopsis: [panic] 8.1-RELEASE "panic: sbdrop" and "panic: sbsndptr: sockbuf _ and mbuf _ clashing" under heavy load Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: brucec Responsible-Changed-When: Wed Jul 21 16:30:32 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=148807 From owner-freebsd-net@FreeBSD.ORG Wed Jul 21 16:34:16 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 E51491065680; Wed, 21 Jul 2010 16:34:16 +0000 (UTC) (envelope-from brucec@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id BBD668FC0C; Wed, 21 Jul 2010 16:34:16 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o6LGYGII019243; Wed, 21 Jul 2010 16:34:16 GMT (envelope-from brucec@freefall.freebsd.org) Received: (from brucec@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o6LGYGd3019239; Wed, 21 Jul 2010 16:34:16 GMT (envelope-from brucec) Date: Wed, 21 Jul 2010 16:34:16 GMT Message-Id: <201007211634.o6LGYGd3019239@freefall.freebsd.org> To: brucec@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: brucec@FreeBSD.org Cc: Subject: Re: kern/137145: [mbuf] [patch] Reference count computing isn't correct when more than one threads call function m_copypacket 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, 21 Jul 2010 16:34:17 -0000 Synopsis: [mbuf] [patch] Reference count computing isn't correct when more than one threads call function m_copypacket Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: brucec Responsible-Changed-When: Wed Jul 21 16:33:57 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=137145 From owner-freebsd-net@FreeBSD.ORG Wed Jul 21 16:35:43 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 5AE761065672; Wed, 21 Jul 2010 16:35:43 +0000 (UTC) (envelope-from brucec@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 32B448FC19; Wed, 21 Jul 2010 16:35:43 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o6LGZhR7019317; Wed, 21 Jul 2010 16:35:43 GMT (envelope-from brucec@freefall.freebsd.org) Received: (from brucec@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o6LGZhpf019313; Wed, 21 Jul 2010 16:35:43 GMT (envelope-from brucec) Date: Wed, 21 Jul 2010 16:35:43 GMT Message-Id: <201007211635.o6LGZhpf019313@freefall.freebsd.org> To: brucec@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: brucec@FreeBSD.org Cc: Subject: Re: kern/87094: 5.4 system with SMP and IPFW crashes under load (mbuf underrun) 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, 21 Jul 2010 16:35:43 -0000 Synopsis: 5.4 system with SMP and IPFW crashes under load (mbuf underrun) Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: brucec Responsible-Changed-When: Wed Jul 21 16:35:28 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=87094 From owner-freebsd-net@FreeBSD.ORG Wed Jul 21 17:02: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 D5448106566B; Wed, 21 Jul 2010 17:02:52 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9A5968FC17; Wed, 21 Jul 2010 17:02:52 +0000 (UTC) Received: by pzk7 with SMTP id 7so2619930pzk.13 for ; Wed, 21 Jul 2010 10:02:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=5QuWPTvSfN0MovryKf+m6k/sfTj2WFYcOiDd+ZXstPs=; b=IuMCPvWQkfUMU3xYLi+zh1PvoheBIdJZl1nmUfhsmJpNNvhvbJYMhEWyPj4QB4CQ6e fiMjxKIZZ2mSpUx+zFW7SRkguev2Vi2gEaJjDhgZVnivn869IBzYfMpXWw80tdGCyzqP nLnjwiZhiqcOp3qrmlbnt9i4OHa9dUNOVswsI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=vMFR6UrkbxLCqMJ0+mBwFr+0ELODpYXAZKMZSu4sS2Fs10qhURI0vacgMlKHDNVD08 hY+MteqkteXvy/9PJjhmWRD2xo+h8jBrwQoOVxNxe2Nrs+iIgArByIffbwwfEwAIkiOw ZdVve+3owweiynBLeumCnWjZxIYd5hSSYHRO4= Received: by 10.114.109.15 with SMTP id h15mr724792wac.105.1279731770890; Wed, 21 Jul 2010 10:02:50 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id n32sm85480350wag.11.2010.07.21.10.02.49 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 21 Jul 2010 10:02:49 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 21 Jul 2010 10:02:01 -0700 From: Pyun YongHyeon Date: Wed, 21 Jul 2010 10:02:01 -0700 To: Kurt Jaeger Message-ID: <20100721170201.GA10798@michelle.cdnetworks.com> References: <201007202234.o6KMY7oV031115@freefall.freebsd.org> <20100721062945.GA51934@home.opsec.eu> <20100721063234.GB51934@home.opsec.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100721063234.GB51934@home.opsec.eu> User-Agent: Mutt/1.4.2.3i Cc: fbsd-pr@opsec.eu, freebsd-net@FreeBSD.org, yongari@FreeBSD.org Subject: Re: kern/148772: [alc] alc0 does not send/receive packets if not plugged in during boot X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 17:02:52 -0000 On Wed, Jul 21, 2010 at 08:32:34AM +0200, Kurt Jaeger wrote: > Hi! > > > A reboot with connected cable follows this evening. > > A reboot with connected cable was booting successfully. > Would you show me verbose dmesg output? With verbose boot alc(4) will show additional information which may help to narrow down the issue. From owner-freebsd-net@FreeBSD.ORG Wed Jul 21 17:06:09 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 BE8AD1065676; Wed, 21 Jul 2010 17:06:09 +0000 (UTC) (envelope-from pi@opsec.eu) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) by mx1.freebsd.org (Postfix) with ESMTP id 72C1A8FC1E; Wed, 21 Jul 2010 17:06:09 +0000 (UTC) Received: from pi by home.opsec.eu with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Obck9-0007bE-VJ; Wed, 21 Jul 2010 19:06:05 +0200 Date: Wed, 21 Jul 2010 19:06:05 +0200 From: Kurt Jaeger To: Pyun YongHyeon Message-ID: <20100721170605.GG51934@home.opsec.eu> References: <201007202234.o6KMY7oV031115@freefall.freebsd.org> <20100721062945.GA51934@home.opsec.eu> <20100721063234.GB51934@home.opsec.eu> <20100721170201.GA10798@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100721170201.GA10798@michelle.cdnetworks.com> Cc: fbsd-pr@opsec.eu, freebsd-net@FreeBSD.org, yongari@FreeBSD.org Subject: Re: kern/148772: [alc] alc0 does not send/receive packets if not plugged in during boot 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, 21 Jul 2010 17:06:09 -0000 Hi! > > > A reboot with connected cable follows this evening. > > > > A reboot with connected cable was booting successfully. > Would you show me verbose dmesg output? > With verbose boot alc(4) will show additional information which may > help to narrow down the issue. http://opsec.eu/backup/alc-bug/dmesg.boot-verbose with the patch applied (and booted with a cable). Before the patch: http://opsec.eu/backup/alc-bug/dmesg.boot Thanks! If you need remote access... -- pi@opsec.eu +49 171 3101372 10 years to go ! From owner-freebsd-net@FreeBSD.ORG Wed Jul 21 18:19: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 28A68106566B; Wed, 21 Jul 2010 18:19:49 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id E1B4E8FC1E; Wed, 21 Jul 2010 18:19:48 +0000 (UTC) Received: by pxi8 with SMTP id 8so3311969pxi.13 for ; Wed, 21 Jul 2010 11:19:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=QCzZ6QgOcvS/C2V7AZtRiMCcSseTJJDlkGyB30F7x40=; b=HRYgTmaZhNwS/rqDPuu6gujJh48bgrN4ugLuMt3jFV7PAoQmvzEiZY0n7cRcS3cg2e Ag1C+uxz2+NdHw4SWtCl/STeG81ShdZOlIw6zcH/iPOHzWXYlsxkTUWTjDmQ0NLNASGW eDe66fHzX5bOH4CAxo9QVj1+K766SQCv6aiPE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=TdANWctt0EIVJcxB7rWbXx6bhX2aiE/hBOTJzdtvEpJtp2yMegWX3jiKjyEIsltli6 E8lsiwZ4D9HyeX0BS8yM6WoRVVwHS6E3bH/x5U82WOAHlrbIhUkAlR1als2y3cQPpw2z ngUCc44PCG4tv/9vsUWjYBdK4Y/YLtUgjqE8Q= Received: by 10.115.106.13 with SMTP id i13mr863011wam.24.1279736376029; Wed, 21 Jul 2010 11:19:36 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id c16sm19930738rvn.1.2010.07.21.11.19.34 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 21 Jul 2010 11:19:35 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 21 Jul 2010 11:18:46 -0700 From: Pyun YongHyeon Date: Wed, 21 Jul 2010 11:18:46 -0700 To: Kurt Jaeger Message-ID: <20100721181846.GB10798@michelle.cdnetworks.com> References: <201007202234.o6KMY7oV031115@freefall.freebsd.org> <20100721062945.GA51934@home.opsec.eu> <20100721063234.GB51934@home.opsec.eu> <20100721170201.GA10798@michelle.cdnetworks.com> <20100721170605.GG51934@home.opsec.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100721170605.GG51934@home.opsec.eu> User-Agent: Mutt/1.4.2.3i Cc: fbsd-pr@opsec.eu, freebsd-net@FreeBSD.org, yongari@FreeBSD.org Subject: Re: kern/148772: [alc] alc0 does not send/receive packets if not plugged in during boot X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 18:19:49 -0000 On Wed, Jul 21, 2010 at 07:06:05PM +0200, Kurt Jaeger wrote: > Hi! > > > > > A reboot with connected cable follows this evening. > > > > > > A reboot with connected cable was booting successfully. > > > Would you show me verbose dmesg output? > > With verbose boot alc(4) will show additional information which may > > help to narrow down the issue. > > http://opsec.eu/backup/alc-bug/dmesg.boot-verbose > One odd thing is alc(4) failed to read station address from EEPROM. So alc(4) assumed BIOS correctly programmed station address but the station address looks wrong to me. How about cold booting? Does other OS also report the same station address? > with the patch applied (and booted with a cable). > > Before the patch: > > http://opsec.eu/backup/alc-bug/dmesg.boot > Would you try this one? http://people.freebsd.org/~yongari/alc/alc.link.patch2 > Thanks! If you need remote access... That does not work mainly because I can't unplug/plug UTP cable through remote access. From owner-freebsd-net@FreeBSD.ORG Wed Jul 21 20:03:34 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 7D5131065687; Wed, 21 Jul 2010 20:03:34 +0000 (UTC) (envelope-from pi@opsec.eu) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) by mx1.freebsd.org (Postfix) with ESMTP id 2FC218FC19; Wed, 21 Jul 2010 20:03:34 +0000 (UTC) Received: from pi by home.opsec.eu with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ObfVs-000ARR-P6; Wed, 21 Jul 2010 22:03:32 +0200 Date: Wed, 21 Jul 2010 22:03:32 +0200 From: Kurt Jaeger To: Pyun YongHyeon Message-ID: <20100721200332.GH51934@home.opsec.eu> References: <201007202234.o6KMY7oV031115@freefall.freebsd.org> <20100721062945.GA51934@home.opsec.eu> <20100721063234.GB51934@home.opsec.eu> <20100721170201.GA10798@michelle.cdnetworks.com> <20100721170605.GG51934@home.opsec.eu> <20100721181846.GB10798@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100721181846.GB10798@michelle.cdnetworks.com> Cc: fbsd-pr@opsec.eu, freebsd-net@FreeBSD.org, yongari@FreeBSD.org Subject: Re: kern/148772: [alc] alc0 does not send/receive packets if not plugged in during boot 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, 21 Jul 2010 20:03:34 -0000 Hi! > > http://opsec.eu/backup/alc-bug/dmesg.boot-verbose > One odd thing is alc(4) failed to read station address from EEPROM. > So alc(4) assumed BIOS correctly programmed station address but the > station address looks wrong to me. > How about cold booting? Does other OS also report the same station > address? I have no other OS at hand right now 8-} > > with the patch applied (and booted with a cable). > > > > Before the patch: > > > > http://opsec.eu/backup/alc-bug/dmesg.boot > > > > Would you try this one? > http://people.freebsd.org/~yongari/alc/alc.link.patch2 It works better, does not hang during boot. Next: add break-to-debugger 8-( > > Thanks! If you need remote access... > > That does not work mainly because I can't unplug/plug UTP cable > through remote access. must.work.on.telekinetic.power 8-) Now, this is going somewhere, as follows: 1) reboot with unplugged cable, then some ifconfig alc0 up/down, then: I ping'ed on the alc0 host and tcpdump on the other host sees some traffic (this failed in the past): 21:19:59.983843 48:5b:39:73:03:4f > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 192.168.5.11 tell 192.168.5.10 21:19:59.983855 00:e0:18:fc:7f:00 > 48:5b:39:73:03:4f, ethertype ARP (0x0806), length 42: arp reply 192.168.5.11 is-at 00:e0:18:fc:7f:00 But: apparently the alc0 does not receive the answer, and so it fails to register the arp. Hmm. 2) reboot with cable plugged in: ping etc works immediatly. 3) shutdown and reboot: ifconfig alc0 says: alc0: flags=8802 metric 0 mtu 1500 options=c3198 ether 48:5b:39:73:03:4f media: Ethernet autoselect then: ndog# ifconfig alc0 192.168.5.10 ndog# ifconfig alc0 alc0: flags=8843 metric 0 mtu 1500 options=c3198 ether 48:5b:39:73:03:4f inet 192.168.5.10 netmask 0xffffff00 broadcast 192.168.5.255 media: Ethernet autoselect (none ) status: no carrier then after a few seconds the netbook just hung 8-( 4) shutdown and reboot from cold, unplugged cable: - started tcpdump on alc0 - plugged in cable - ifconfig alc0 192.168.5.10 whow, it works. I then unplugged, replugged etc. Looks stable now. Did some ipv6 over it. Rebooted with this as the primary interface. Works fine. Cool. Thank you very much. -- pi@opsec.eu +49 171 3101372 10 years to go ! From owner-freebsd-net@FreeBSD.ORG Wed Jul 21 20:48: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 E7E051065672; Wed, 21 Jul 2010 20:48:07 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id ABEA98FC17; Wed, 21 Jul 2010 20:48:07 +0000 (UTC) Received: by pvh1 with SMTP id 1so3217070pvh.13 for ; Wed, 21 Jul 2010 13:48:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=Dhses1smW2EyMvHCt4pFEtx9apGVpwssadL7KM9uoYA=; b=OyXweEQocLEpG9AtDXdQTEURfLWYvdbYORZZO8oD9afXBOCUKxN+31Vn/RzfGbOrnx Vbcxrn9Y6gl717MY/FWHZJzIf88d3E+A+qqLUJ3q6m+vB7mPgLguBpU/N9JH94P/Oxm8 ObEt2978+M2rINPlfadQ+x80dCbliYYMXAFXY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=ApU6dvv0p1naDVs2qwF8vY6LLkL4e18R7V/V+QNU59o0QB+v+5k/qSQ/fgZPmWzCK/ dceySN+vC6OhzAl1siKoXlRxz2xfSXqv3uiWMmcb+FIoPV8S31fqg0OyQS0bsWf7Z7Os +P0x4AxTq7FQOLVpYle7jQBtLvUsRylMIJS9E= Received: by 10.142.216.21 with SMTP id o21mr869890wfg.153.1279745284905; Wed, 21 Jul 2010 13:48:04 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id w8sm9496607wfd.7.2010.07.21.13.48.03 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 21 Jul 2010 13:48:04 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 21 Jul 2010 13:47:15 -0700 From: Pyun YongHyeon Date: Wed, 21 Jul 2010 13:47:15 -0700 To: Kurt Jaeger Message-ID: <20100721204715.GC10798@michelle.cdnetworks.com> References: <201007202234.o6KMY7oV031115@freefall.freebsd.org> <20100721062945.GA51934@home.opsec.eu> <20100721063234.GB51934@home.opsec.eu> <20100721170201.GA10798@michelle.cdnetworks.com> <20100721170605.GG51934@home.opsec.eu> <20100721181846.GB10798@michelle.cdnetworks.com> <20100721200332.GH51934@home.opsec.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100721200332.GH51934@home.opsec.eu> User-Agent: Mutt/1.4.2.3i Cc: fbsd-pr@opsec.eu, freebsd-net@FreeBSD.org, yongari@FreeBSD.org Subject: Re: kern/148772: [alc] alc0 does not send/receive packets if not plugged in during boot X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 20:48:08 -0000 On Wed, Jul 21, 2010 at 10:03:32PM +0200, Kurt Jaeger wrote: > Hi! > > > > http://opsec.eu/backup/alc-bug/dmesg.boot-verbose > > > One odd thing is alc(4) failed to read station address from EEPROM. > > So alc(4) assumed BIOS correctly programmed station address but the > > station address looks wrong to me. > > > How about cold booting? Does other OS also report the same station > > address? > > I have no other OS at hand right now 8-} > > > > with the patch applied (and booted with a cable). > > > > > > Before the patch: > > > > > > http://opsec.eu/backup/alc-bug/dmesg.boot > > > > > > > Would you try this one? > > http://people.freebsd.org/~yongari/alc/alc.link.patch2 > > It works better, does not hang during boot. > > Next: add break-to-debugger 8-( > > > > Thanks! If you need remote access... > > > > That does not work mainly because I can't unplug/plug UTP cable > > through remote access. > > must.work.on.telekinetic.power 8-) > > Now, this is going somewhere, as follows: > > 1) > reboot with unplugged cable, then some ifconfig alc0 up/down, then: > I ping'ed on the alc0 host and tcpdump on the other host sees some traffic > (this failed in the past): > > 21:19:59.983843 48:5b:39:73:03:4f > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 192.168.5.11 tell 192.168.5.10 > 21:19:59.983855 00:e0:18:fc:7f:00 > 48:5b:39:73:03:4f, ethertype ARP (0x0806), length 42: arp reply 192.168.5.11 is-at 00:e0:18:fc:7f:00 > > But: apparently the alc0 does not receive the answer, and so it > fails to register the arp. > > Hmm. > > 2) reboot with cable plugged in: ping etc works immediatly. > > 3) shutdown and reboot: > > ifconfig alc0 says: > > alc0: flags=8802 metric 0 mtu 1500 > options=c3198 > ether 48:5b:39:73:03:4f > media: Ethernet autoselect > > then: > > ndog# ifconfig alc0 192.168.5.10 > ndog# ifconfig alc0 > alc0: flags=8843 metric 0 mtu 1500 > options=c3198 > ether 48:5b:39:73:03:4f > inet 192.168.5.10 netmask 0xffffff00 broadcast 192.168.5.255 > media: Ethernet autoselect (none ) > status: no carrier > > then after a few seconds the netbook just hung 8-( > > 4) shutdown and reboot from cold, unplugged cable: > > - started tcpdump on alc0 > - plugged in cable > - ifconfig alc0 192.168.5.10 > > whow, it works. > > I then unplugged, replugged etc. Looks stable now. Did some ipv6 over > it. Rebooted with this as the primary interface. Works fine. > > Cool. Thank you very much. > Ok, it seems it shows some mixed result. It's possible that warm boot may not clear some power related configuration of system which could be incorrectly programmed with stock alc(4). So start testing from cold booting with/without UTP cable and see whether alc(4) can establish a valid link with link partner. You should never see "" media. If that works as expected, test warm booting with/without UTP cable. From owner-freebsd-net@FreeBSD.ORG Wed Jul 21 22:31: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 9BA951065676; Wed, 21 Jul 2010 22:31:03 +0000 (UTC) (envelope-from brucec@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 727A78FC12; Wed, 21 Jul 2010 22:31:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o6LMV3f8072994; Wed, 21 Jul 2010 22:31:03 GMT (envelope-from brucec@freefall.freebsd.org) Received: (from brucec@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o6LMV368072979; Wed, 21 Jul 2010 22:31:03 GMT (envelope-from brucec) Date: Wed, 21 Jul 2010 22:31:03 GMT Message-Id: <201007212231.o6LMV368072979@freefall.freebsd.org> To: cdu@ucr.edu, brucec@FreeBSD.org, freebsd-net@FreeBSD.org From: brucec@FreeBSD.org Cc: Subject: Re: kern/87094: 5.4 system with SMP and IPFW crashes under load (mbuf underrun) 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, 21 Jul 2010 22:31:03 -0000 Synopsis: 5.4 system with SMP and IPFW crashes under load (mbuf underrun) State-Changed-From-To: suspended->closed State-Changed-By: brucec State-Changed-When: Wed Jul 21 22:30:29 UTC 2010 State-Changed-Why: FreeBSD 5.x is no longer supported. http://www.freebsd.org/cgi/query-pr.cgi?pr=87094 From owner-freebsd-net@FreeBSD.ORG Thu Jul 22 12:55: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 D08651065670 for ; Thu, 22 Jul 2010 12:55:59 +0000 (UTC) (envelope-from grand@mindless.gr) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6F92F8FC14 for ; Thu, 22 Jul 2010 12:55:58 +0000 (UTC) Received: by eyh6 with SMTP id 6so2200144eyh.13 for ; Thu, 22 Jul 2010 05:55:58 -0700 (PDT) Received: by 10.213.34.77 with SMTP id k13mr1653096ebd.77.1279803355759; Thu, 22 Jul 2010 05:55:55 -0700 (PDT) Received: from [78.108.47.251] ([78.108.47.251]) by mx.google.com with ESMTPS id v8sm55219387eeh.8.2010.07.22.05.55.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 22 Jul 2010 05:55:54 -0700 (PDT) From: "Thodoris S." Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Jul 2010 15:55:50 +0300 Message-Id: <403BAEC0-7D73-4584-9D4D-20B642DB938B@gmail.com> To: freebsd-net@freebsd.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: FreeBSD + Quagga OSPFD issue X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 12:55:59 -0000 Hello, i am experiencing a weird problem,=20 i have set up a FreeBSD 8.0 Release, with Quagga 0.9.15 running ospfd = and bgpd for a small network the router has multiple ethernet interfaces for backup in my case 2.If i = disconnect an ethernet either Physical or Logical (ifconfig em1 down) when it comes up again after a while, Quagga doesnt use it as OSPF = interface below i am giving you some console outputs to undestand better = the issue #1 show ip ospf interfaces: em1 is up ifindex 2, MTU 1500 bytes, BW 0 Kbit = Internet Address 10.10.32.34/30, Broadcast 10.10.32.35, Area 0.0.0.0 MTU mismatch detection:enabled Router ID 10.10.32.39, Network Type BROADCAST, Cost: 10 Transmit Delay is 1 sec, State Backup, Priority 1 Designated Router (ID) 10.10.32.36, Interface Address 10.10.32.33 Backup Designated Router (ID) 10.10.32.39, Interface Address = 10.10.32.34 Multicast group memberships: OSPFAllRouters OSPFDesignatedRouters Timer intervals configured, Hello 10s, Dead 40s, Wait 40s, Retransmit = 5 Hello due in 0.901s Neighbor Count is 1, Adjacent neighbor count is 1 #2 ifconfig em1 down #3 ifconfig em1 up #4 show ip ospf interfaces: em1 is up ifindex 3, MTU 1500 bytes, BW 0 Kbit = OSPF not enabled on this interface Anyone has any idea on this issue? i have searched the internet and some = people seem to have the same problem all with FreeBSD, Linux version = dosnt have this problem, some of them speaking for a patch floating = arround, but i didnt find any information on it i have changed the version of quagga from 0.9.15 to 0.9.16 but not = solved, i have compiled the quagga with TCP SOCKETS support but again = the problem dosnt solve, the only workaround is to reboot the whole = machine even if i restart quagga it doesnt work.=20 Thanks in advance= From owner-freebsd-net@FreeBSD.ORG Thu Jul 22 15:20: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 18C821065708 for ; Thu, 22 Jul 2010 15:20: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 0952E8FC21 for ; Thu, 22 Jul 2010 15:20:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o6MFK2BA084643 for ; Thu, 22 Jul 2010 15:20:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o6MFK221084642; Thu, 22 Jul 2010 15:20:02 GMT (envelope-from gnats) Date: Thu, 22 Jul 2010 15:20:02 GMT Message-Id: <201007221520.o6MFK221084642@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Gleb Smirnoff Cc: Subject: Re: kern/148784: arp pub not working properly X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Gleb Smirnoff List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 15:20:03 -0000 The following reply was made to PR kern/148784; it has been noted by GNATS. From: Gleb Smirnoff To: grayich Cc: freebsd-gnats-submit@FreeBSD.org Subject: Re: kern/148784: arp pub not working properly Date: Thu, 22 Jul 2010 19:11:18 +0400 --VS++wcV0S1rZb1Fb Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Please try the attached patch and report whether it works. -- Totus tuus, Glebius. --VS++wcV0S1rZb1Fb Content-Type: text/x-diff; charset=koi8-r Content-Disposition: attachment; filename="if_llatbl.c.diff" Index: if_llatbl.c =================================================================== --- if_llatbl.c (revision 210371) +++ if_llatbl.c (working copy) @@ -337,6 +337,7 @@ * LLE_DELETED flag, and reset the expiration timer */ bcopy(LLADDR(dl), &lle->ll_addr, ifp->if_addrlen); + lle->la_flags |= (flags & (LLE_PUB | LLE_PROXY)); lle->la_flags |= LLE_VALID; lle->la_flags &= ~LLE_DELETED; #ifdef INET6 --VS++wcV0S1rZb1Fb-- From owner-freebsd-net@FreeBSD.ORG Thu Jul 22 20:03:05 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 CC14C1065672; Thu, 22 Jul 2010 20:03:05 +0000 (UTC) (envelope-from weongyo@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A446F8FC22; Thu, 22 Jul 2010 20:03:05 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o6MK35tu065260; Thu, 22 Jul 2010 20:03:05 GMT (envelope-from weongyo@freefall.freebsd.org) Received: (from weongyo@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o6MK359C065256; Thu, 22 Jul 2010 20:03:05 GMT (envelope-from weongyo) Date: Thu, 22 Jul 2010 20:03:05 GMT Message-Id: <201007222003.o6MK359C065256@freefall.freebsd.org> To: weongyo@FreeBSD.org, freebsd-net@FreeBSD.org, weongyo@FreeBSD.org From: weongyo@FreeBSD.org Cc: Subject: Re: kern/144505: [bwn] [patch] Error in macro CALC_COEFF2. 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, 22 Jul 2010 20:03:05 -0000 Synopsis: [bwn] [patch] Error in macro CALC_COEFF2. Responsible-Changed-From-To: freebsd-net->weongyo Responsible-Changed-By: weongyo Responsible-Changed-When: Thu Jul 22 20:02:51 UTC 2010 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=144505 From owner-freebsd-net@FreeBSD.ORG Fri Jul 23 01:02:22 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 B9D911065670; Fri, 23 Jul 2010 01:02:22 +0000 (UTC) (envelope-from alancyang@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 67B388FC1F; Fri, 23 Jul 2010 01:02:22 +0000 (UTC) Received: by gwj23 with SMTP id 23so575205gwj.13 for ; Thu, 22 Jul 2010 18:02:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=oYzx/hVIaUleQWBpS5Qi9iAilAy/8Q4tnqL7DGqEiWs=; b=Rbdx4AFTYGn23MD/ozCedp7kPZqts7SRozZzhkJHBN3qgV0E6SMSAg3hfyfhjdIJQX 2lbNqF21j/1/fnYGLzFAI+J28+9Xqh0i1kGQZ+IjjXWQFtb7yAd3wUWYuYQveLixA4yR vI4p9Vd3WTbTTOUr5+d7m8+vSPi3j5M+g4DaI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Sm4PGDKc8sedsvTbP+vAlLwVA3xcizrXF9yPxa9GnCOOU4Ac/JPdIcDdr2Lz+zcozU 2tHBRkSu5Uc3Un7WmU5YgYuwZgsNUnC0UsVszBUFC2yC/WE1ARtD8Lp3Wn9ssT/7ZiWb DRFW0dPB9bzT2+8C1kAubr4UuSfEAAVtCwS1k= MIME-Version: 1.0 Received: by 10.100.111.7 with SMTP id j7mr3089132anc.30.1279845269103; Thu, 22 Jul 2010 17:34:29 -0700 (PDT) Received: by 10.100.123.3 with HTTP; Thu, 22 Jul 2010 17:34:29 -0700 (PDT) Date: Thu, 22 Jul 2010 17:34:29 -0700 Message-ID: From: alan yang To: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: interface for import/export flowtable 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, 23 Jul 2010 01:02:22 -0000 Hello, Wonder people had implemented interface to import / export flowtable. Thanks in advance for sharing the info. Alan From owner-freebsd-net@FreeBSD.ORG Fri Jul 23 07:40: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 8A7A7106567D for ; Fri, 23 Jul 2010 07:40:52 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: from zibbi.meraka.csir.co.za (unknown [IPv6:2001:4200:7000:2::1]) by mx1.freebsd.org (Postfix) with ESMTP id 7A1D88FC0C for ; Fri, 23 Jul 2010 07:40:50 +0000 (UTC) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id BFCBD39822; Fri, 23 Jul 2010 09:40:47 +0200 (SAST) Date: Fri, 23 Jul 2010 09:40:47 +0200 From: John Hay To: freebsd-net@freebsd.org, jfvogel@gmail.com Message-ID: <20100723074047.GA47514@zibbi.meraka.csir.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: packet loss on ixgbe using vlans and routing 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, 23 Jul 2010 07:40:52 -0000 Hi, (Jack any chance that you can look at this please?) It looks like there are 2 problems with the ixgbe driver on FreeBSD-8. I have a Dell T710 with 4 X 10G ethernet interfaces (2 X Dual port Intel 82599 cards). It is running FreeBSD RELENG_8. 1 - When routing (using vlans) there is heavy packet loss that go away when you do "ifconfig ix2 -rxcsum". The packet loss seems to be on the receive side because I do not see them on the receiving interface with tcpdump. This seems to impact both ipv4 and ipv6. My test setup is the Dell T710 with its ix2 connected to a 10G port of a Nortel 4526GTX. On that port I have 2 vlans configured with half of the 1G ports in the one vlan and the other half in the other vlan. If I test with iperf from one of the machines on a 1G port to the T710, I get 920Mbit/s. If I do it simultaneously from a few machines connected to the 1G ports, all of them basically saturate their 1G links. If I now try to route from the one vlan to the other, ie. doing an iperf from a 1G connected machine, through the T710, to another 1G connected machine, I see packet loss, sometimes iperf is only able to do 100kbits/s. (Configuring a tcp relay, like socat, on the T710, and working through it, I again get 900Mbit/s and more.) So it seems that as long as the T710 with the 10G card is the start or end point of the connection, I get no packet loss, but as soon as it has to route, something go wrong. 2 - I see packet loss (0 - 40%) on IPv6 packets in vlans, when the machine is not the originator of the packets. This happen even with the "ifconfig ix2 -rxcsum". Let me try to describe a little more. If a neigbouring machine ping6 it, there will be packet loss. If it act as a router for ipv6, there will be packet loss. This happen even when the network is pretty idle and with different switches (Nortel and Cisco equipment). The packet loss is very fluctuating. Pinging 1000 packets might loose 1% one time and the next time 30%. Looking with tcpdump, I can see the packets arriving and going out, but the packet never arrive at the next machine. (My feeling is that they get lost inside the card.) The error counters on the switch does not increment. I do not see packet loss if the machine originate the packets, for example ping6 from the machine. Also ipv4 packets do not have any packets loss. If I do not use vlans, I don't see packet loss with ipv6 either. The machine also have bce 1G interfaces and I do not see the packet loss on them. Here is some info about the machine / setup. The numbers are pretty low because I rebooted after compiling a kernel with IPFIREWALL, ROUTETABLES, MROUTING and FLOWTABLE removed. I'll add my kernel config file with empty and commented out lines removed. pciconf -lvc ix0@pci0:129:0:0: class=0x020000 card=0x00038086 chip=0x10fb8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet cap 01[40] = powerspec 3 supports D0 D3 current D0 cap 05[50] = MSI supports 1 message, 64 bit, vector masks cap 11[70] = MSI-X supports 64 messages in map 0x20 enabled cap 10[a0] = PCI-Express 2 endpoint max data 256(512) link x8(x8) ix1@pci0:129:0:1: class=0x020000 card=0x00038086 chip=0x10fb8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet cap 01[40] = powerspec 3 supports D0 D3 current D0 cap 05[50] = MSI supports 1 message, 64 bit, vector masks cap 11[70] = MSI-X supports 64 messages in map 0x20 enabled cap 10[a0] = PCI-Express 2 endpoint max data 256(512) link x8(x8) ix2@pci0:131:0:0: class=0x020000 card=0x00038086 chip=0x10fb8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet cap 01[40] = powerspec 3 supports D0 D3 current D0 cap 05[50] = MSI supports 1 message, 64 bit, vector masks cap 11[70] = MSI-X supports 64 messages in map 0x20 enabled cap 10[a0] = PCI-Express 2 endpoint max data 256(512) link x8(x8) ix3@pci0:131:0:1: class=0x020000 card=0x00038086 chip=0x10fb8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet cap 01[40] = powerspec 3 supports D0 D3 current D0 cap 05[50] = MSI supports 1 message, 64 bit, vector masks cap 11[70] = MSI-X supports 64 messages in map 0x20 enabled cap 10[a0] = PCI-Express 2 endpoint max data 256(512) link x8(x8) output of vmstat -i interrupt total rate irq19: ehci0 28371 0 irq21: uhci2 uhci4+ 48 0 irq23: atapci0 46 0 irq34: mpt0 146954 2 cpu0: timer 112205297 1999 irq256: bce0 52063 0 irq257: bce1 1 0 irq258: bce2 1 0 irq259: bce3 1 0 irq260: ix0:que 0 142258 2 irq261: ix0:que 1 56464 1 irq262: ix0:que 2 56199 1 irq263: ix0:que 3 56198 1 irq264: ix0:que 4 66569 1 irq265: ix0:que 5 56148 1 irq266: ix0:que 6 56217 1 irq267: ix0:que 7 56311 1 irq268: ix0:que 8 56169 1 irq269: ix0:que 9 69485 1 irq270: ix0:que 10 56176 1 irq271: ix0:que 11 56205 1 irq272: ix0:que 12 56281 1 irq273: ix0:que 13 56359 1 irq274: ix0:que 14 56292 1 irq275: ix0:que 15 56197 1 irq276: ix0:link 2 0 irq277: ix1:que 0 107873 1 irq278: ix1:que 1 56094 0 irq279: ix1:que 2 56097 0 irq280: ix1:que 3 56096 0 irq281: ix1:que 4 65439 1 irq282: ix1:que 5 56091 0 irq283: ix1:que 6 56092 0 irq284: ix1:que 7 56098 0 irq285: ix1:que 8 56091 0 irq286: ix1:que 9 56096 0 irq287: ix1:que 10 56093 0 irq288: ix1:que 11 56091 0 irq289: ix1:que 12 56096 0 irq290: ix1:que 13 56095 0 irq291: ix1:que 14 57125 1 irq292: ix1:que 15 56093 0 irq293: ix1:link 1 0 irq294: ix2:que 0 231250 4 irq295: ix2:que 1 57784 1 irq296: ix2:que 2 69956 1 irq297: ix2:que 3 59498 1 irq298: ix2:que 4 58201 1 irq299: ix2:que 5 58599 1 irq300: ix2:que 6 57813 1 irq301: ix2:que 7 60075 1 irq302: ix2:que 8 68639 1 irq303: ix2:que 9 58194 1 irq304: ix2:que 10 60752 1 irq305: ix2:que 11 57628 1 irq306: ix2:que 12 66796 1 irq307: ix2:que 13 63307 1 irq308: ix2:que 14 60788 1 irq309: ix2:que 15 59102 1 irq310: ix2:link 5 0 irq311: ix3:que 0 56090 0 irq312: ix3:que 1 56090 0 irq313: ix3:que 2 56090 0 irq314: ix3:que 3 56090 0 irq315: ix3:que 4 56090 0 irq316: ix3:que 5 56090 0 irq317: ix3:que 6 56090 0 irq318: ix3:que 7 56090 0 irq319: ix3:que 8 56090 0 irq320: ix3:que 9 56090 0 irq321: ix3:que 10 56090 0 irq322: ix3:que 11 56090 0 irq323: ix3:que 12 56090 0 irq324: ix3:que 13 56090 0 irq325: ix3:que 14 56090 0 irq326: ix3:que 15 56090 0 cpu1: timer 112196134 1999 cpu10: timer 112196179 1999 cpu3: timer 112196135 1999 cpu8: timer 112196108 1999 cpu4: timer 112196161 1999 cpu11: timer 112196179 1999 cpu5: timer 112196161 1999 cpu13: timer 112196179 1999 cpu6: timer 112196161 1999 cpu14: timer 112196179 1999 cpu2: timer 112196106 1999 cpu12: timer 112196179 1999 cpu7: timer 112196161 1999 cpu9: timer 112196155 1999 cpu15: timer 112196179 1999 Total 1799390156 32072 netstat -m 133178/4042/137220 mbufs in use (current/cache/total) 133112/2062/135174/262144 mbuf clusters in use (current/cache/total/max) 133112/2056 mbuf+clusters out of packet secondary zone in use (current/cache) 0/20/20/131072 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/65536 9k jumbo clusters in use (current/cache/total/max) 0/0/0/32768 16k jumbo clusters in use (current/cache/total/max) 299518K/5214K/304733K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines kernel config file, basically started with 64 bit and removed the stuff I do not need. cpu HAMMER ident SEEKAT device ipmi makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols options SCHED_ULE # ULE scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options INET6 # IPv6 communications protocols options SCTP # Stream Control Transmission Protocol options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_DIRHASH # Improve performance on big directories options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_PART_GPT # GUID Partition Tables. options GEOM_LABEL # Provides labelization options COMPAT_43TTY # BSD 4.3 TTY compat (sgtty) options COMPAT_IA32 # Compatible with i386 binaries options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options COMPAT_FREEBSD7 # Compatible with FreeBSD7 options KTRACE # ktrace(1) support options STACK # stack(9) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options P1003_1B_SEMAPHORES # POSIX-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options PRINTF_BUFR_SIZE=128 # Prevent printf output being interspersed. options KBD_INSTALL_CDEV # install a CDEV entry in /dev options HWPMC_HOOKS # Necessary kernel hooks for hwpmc(4) options INCLUDE_CONFIG_FILE # Include this file in kernel options SMP # Symmetric MultiProcessor Kernel device cpufreq device acpi device pci device ata device atapicd # ATAPI CDROM drives device mpt # LSI-Logic MPT-Fusion device scbus # SCSI bus (required for SCSI) device da # Direct Access (disks) device pass # Passthrough device (direct SCSI access) device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device kbdmux # keyboard multiplexer device vga # VGA video card driver device splash # Splash screen and screen saver support device sc device agp # support several AGP chipsets device uart # Generic UART driver device loop # Network loopback device random # Entropy device device ether # Ethernet support device pty # BSD-style compatibility pseudo ttys device bpf # Berkeley packet filter device uhci # UHCI PCI->USB interface device ehci # EHCI PCI->USB interface (USB 2.0) device usb # USB Bus (required) device uhid # "Human Interface Devices" device ukbd # Keyboard device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse kldstat Id Refs Address Size Name 1 55 0xffffffff80100000 6ea290 kernel 2 1 0xffffffff807eb000 19e088 zfs.ko 3 2 0xffffffff8098a000 3860 opensolaris.ko 4 2 0xffffffff8098e000 20448 krpc.ko 5 1 0xffffffff809af000 21100 geom_mirror.ko 6 1 0xffffffff809d1000 66c0 if_vlan.ko 7 1 0xffffffff809d8000 506c8 if_bce.ko 8 2 0xffffffff80a29000 3ec20 miibus.ko 9 1 0xffffffff80a68000 243e0 if_ixgbe.ko 10 1 0xffffffff80a8d000 1e08 coretemp.ko ifconfig ix2 (with -rxcsum and global addrs modified) ix2: flags=8843 metric 0 mtu 1500 options=5b8 ether 00:1b:21:57:ef:7c inet6 fe80::21b:21ff:fe57:ef7c%ix2 prefixlen 64 scopeid 0x3 nd6 options=3 media: Ethernet autoselect (10Gbase-SR ) status: active ifconfig ix2.1 ix2.1: flags=8843 metric 0 mtu 1500 ether 00:1b:21:57:ef:7c inet 10.0.28.2 netmask 0xffffff00 broadcast 10.0.28.255 inet6 fe80::21b:21ff:fe57:b420%ix2.1 prefixlen 64 scopeid 0x9 inet6 2001:0:0:3:21b:21ff:fe57:b420 prefixlen 64 inet6 2001:0:0:3:: prefixlen 64 anycast nd6 options=3 media: Ethernet autoselect (10Gbase-SR ) status: active vlan: 1 parent interface: ix2 ifconfig ix2.8 ix2.8: flags=8843 metric 0 mtu 1500 ether 00:1b:21:57:ef:7c inet 10.0.8.50 netmask 0xffffff00 broadcast 10.0.8.255 inet6 fe80::21b:21ff:fe57:b420%ix2.8 prefixlen 64 scopeid 0xa inet6 2001:0:0:1:21b:21ff:fe57:b420 prefixlen 64 inet6 2001:0:0:1:: prefixlen 64 anycast nd6 options=3 media: Ethernet autoselect (10Gbase-SR ) status: active vlan: 8 parent interface: ix2 John -- John Hay -- jhay@meraka.csir.co.za / jhay@FreeBSD.org From owner-freebsd-net@FreeBSD.ORG Fri Jul 23 08:12:32 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 0691C106566C for ; Fri, 23 Jul 2010 08:12:32 +0000 (UTC) (envelope-from buchtajz@borsice.net) Received: from mx.sitkom.cz (mx.sitkom.cz [109.164.0.132]) by mx1.freebsd.org (Postfix) with ESMTP id AF1438FC12 for ; Fri, 23 Jul 2010 08:12:31 +0000 (UTC) Received: from spamd.mail.sitkom.cz (mail.mx.sitkom.cz [10.13.126.5]) by mx.mail.sitkom.cz (Postfix) with ESMTP id E31411C66DE; Fri, 23 Jul 2010 10:12:28 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.mx.sitkom.cz X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_FRT_BELOW2 autolearn=ham version=3.3.1 Received: from avscan.mail.sitkom.cz (mx.sitkom.cz [109.164.0.132]) by spamd.mail.sitkom.cz (Postfix) with ESMTP id BC9041C66CE; Fri, 23 Jul 2010 10:12:28 +0200 (CEST) Received: from [10.8.20.20] (buchtajz-notebook-lan.brestek.sfn [10.8.20.20]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx.sitkom.cz (Postfix) with ESMTPSA id 0FE441C66CC; Fri, 23 Jul 2010 10:12:28 +0200 (CEST) Message-ID: <4C494EC7.6080309@borsice.net> Date: Fri, 23 Jul 2010 10:11:51 +0200 From: Michal Buchtik User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.10) Gecko/20100622 Thunderbird/3.0.5 MIME-Version: 1.0 To: "Thodoris S." References: <403BAEC0-7D73-4584-9D4D-20B642DB938B@gmail.com> In-Reply-To: <403BAEC0-7D73-4584-9D4D-20B642DB938B@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD + Quagga OSPFD issue X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2010 08:12:32 -0000 Hi we have this problem too, see bellow On 2010/07/22 14:55, Thodoris S. wrote: > Hello, i am experiencing a weird problem, > > i have set up a FreeBSD 8.0 Release, with Quagga 0.9.15 running ospfd and bgpd for a small network > the router has multiple ethernet interfaces for backup in my case 2.If i disconnect an ethernet either Physical or Logical (ifconfig em1 down) > when it comes up again after a while, Quagga doesnt use it as OSPF interface below i am giving you some console outputs to undestand better the issue > > #1 show ip ospf interfaces: > em1 is up > ifindex 2, MTU 1500 bytes, BW 0 Kbit > Internet Address 10.10.32.34/30, Broadcast 10.10.32.35, Area 0.0.0.0 > MTU mismatch detection:enabled > Router ID 10.10.32.39, Network Type BROADCAST, Cost: 10 > Transmit Delay is 1 sec, State Backup, Priority 1 > Designated Router (ID) 10.10.32.36, Interface Address 10.10.32.33 > Backup Designated Router (ID) 10.10.32.39, Interface Address 10.10.32.34 > Multicast group memberships: OSPFAllRouters OSPFDesignatedRouters > Timer intervals configured, Hello 10s, Dead 40s, Wait 40s, Retransmit 5 > Hello due in 0.901s > Neighbor Count is 1, Adjacent neighbor count is 1 > > > #2 ifconfig em1 down > #3 ifconfig em1 up > #4 show ip ospf interfaces: > em1 is up > ifindex 3, MTU 1500 bytes, BW 0 Kbit > OSPF not enabled on this interface > > Check route table for prefix 10.10.32.32/30. I think, that it will be type UG1, because quagga installed it when the interface was down (ospfd deamon received it over another link). > Anyone has any idea on this issue? i have searched the internet and some people seem to have the same problem all with FreeBSD, Linux version dosnt have this problem, some of them speaking for a patch floating arround, but i didnt find any information on it > i have changed the version of quagga from 0.9.15 to 0.9.16 but not solved, i have compiled the quagga with TCP SOCKETS support but again the problem dosnt solve, the only workaround is to reboot the whole machine > even if i restart quagga it doesnt work. > Workaround is to add route manually, like this: route delete 10.10.32.32/30; route add 10.10.32.32/30 -iface em0 or route delete 10.10.32.32/30; ifconfig em0 10.10.32.34/30 I think freebsd kernel could install "connected" route when interface goas up (and replace UG1 route) because connected could be preferred over dynamic route. So this seems like FreeBSD bug , instead of quagga ones. Michal From owner-freebsd-net@FreeBSD.ORG Fri Jul 23 08:36: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 9E17B106566C for ; Fri, 23 Jul 2010 08:36:12 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 43A4D8FC13 for ; Fri, 23 Jul 2010 08:36:11 +0000 (UTC) Received: by gyg4 with SMTP id 4so1537059gyg.13 for ; Fri, 23 Jul 2010 01:36:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=/6Wbtj55FB/8mSDWtbDvKNb7wkXUUF7S3k7aJRv59as=; b=ifXZH12b/2vM1wOZO1ojnCprbAXrovw5WIbQGRqASxfo/Rdz+Y0GjHprAjRqFcG7E5 rSb3MtuQWERCoAuRqH6Bz7Cn+AgxOBPj/86DJtaBsXswJMmPUYVEUcmqRIaCdmGik9sw YqMgJ9kpzCfGq/hoVcNAUMWdiVgdZOhzjd6pI= 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=rgMifxMXK7hYWf7kf6qHLHRHSxX0xICCWfpC4HTOKs7LC1eLGKeaAUgLAdSyoiUaBC IZYHNVhHKzoaFGeDbG8pcxz+/r6ByVVGFSWknMWfqCw7Fh/ONMFm5VqrreAXJrDpH+ix prqRy50nFhkAYnbnG6AZ6Qp4OFbncgkZM6Cpk= MIME-Version: 1.0 Received: by 10.150.202.9 with SMTP id z9mr5225076ybf.87.1279874170954; Fri, 23 Jul 2010 01:36:10 -0700 (PDT) Received: by 10.229.26.15 with HTTP; Fri, 23 Jul 2010 01:36:10 -0700 (PDT) In-Reply-To: <20100723074047.GA47514@zibbi.meraka.csir.co.za> References: <20100723074047.GA47514@zibbi.meraka.csir.co.za> Date: Fri, 23 Jul 2010 01:36:10 -0700 Message-ID: From: Jack Vogel To: John Hay Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: packet loss on ixgbe using vlans and routing 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, 23 Jul 2010 08:36:12 -0000 Yes, I am here, I have been reading this, but I am also very busy with a couple of things, please be patient, I will get on this asap. Cheers, Jack On Fri, Jul 23, 2010 at 12:40 AM, John Hay wrote: > Hi, > > (Jack any chance that you can look at this please?) > > It looks like there are 2 problems with the ixgbe driver on FreeBSD-8. > I have a Dell T710 with 4 X 10G ethernet interfaces (2 X Dual port Intel > 82599 cards). It is running FreeBSD RELENG_8. > > 1 - When routing (using vlans) there is heavy packet loss that go away > when you do "ifconfig ix2 -rxcsum". The packet loss seems to be on the > receive side because I do not see them on the receiving interface with > tcpdump. This seems to impact both ipv4 and ipv6. > > My test setup is the Dell T710 with its ix2 connected to a 10G port of > a Nortel 4526GTX. On that port I have 2 vlans configured with half of > the 1G ports in the one vlan and the other half in the other vlan. > > If I test with iperf from one of the machines on a 1G port to the T710, > I get 920Mbit/s. If I do it simultaneously from a few machines connected > to the 1G ports, all of them basically saturate their 1G links. > > If I now try to route from the one vlan to the other, ie. doing an iperf > from a 1G connected machine, through the T710, to another 1G connected > machine, I see packet loss, sometimes iperf is only able to do 100kbits/s. > (Configuring a tcp relay, like socat, on the T710, and working through it, > I again get 900Mbit/s and more.) > > So it seems that as long as the T710 with the 10G card is the start or > end point of the connection, I get no packet loss, but as soon as it > has to route, something go wrong. > > 2 - I see packet loss (0 - 40%) on IPv6 packets in vlans, when the > machine is not the originator of the packets. This happen even with > the "ifconfig ix2 -rxcsum". > > Let me try to describe a little more. If a neigbouring machine ping6 it, > there will be packet loss. If it act as a router for ipv6, there will be > packet loss. This happen even when the network is pretty idle and with > different switches (Nortel and Cisco equipment). The packet loss is > very fluctuating. Pinging 1000 packets might loose 1% one time and the > next time 30%. Looking with tcpdump, I can see the packets arriving and > going out, but the packet never arrive at the next machine. (My feeling is > that they get lost inside the card.) The error counters on the switch > does not increment. > > I do not see packet loss if the machine originate the packets, for example > ping6 from the machine. Also ipv4 packets do not have any packets loss. If > I do not use vlans, I don't see packet loss with ipv6 either. > > The machine also have bce 1G interfaces and I do not see the packet loss > on them. > > Here is some info about the machine / setup. The numbers are pretty low > because I rebooted after compiling a kernel with IPFIREWALL, ROUTETABLES, > MROUTING and FLOWTABLE removed. I'll add my kernel config file with empty > and commented out lines removed. > > pciconf -lvc > ix0@pci0:129:0:0: class=0x020000 card=0x00038086 chip=0x10fb8086 > rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > class = network > subclass = ethernet > cap 01[40] = powerspec 3 supports D0 D3 current D0 > cap 05[50] = MSI supports 1 message, 64 bit, vector masks > cap 11[70] = MSI-X supports 64 messages in map 0x20 enabled > cap 10[a0] = PCI-Express 2 endpoint max data 256(512) link x8(x8) > ix1@pci0:129:0:1: class=0x020000 card=0x00038086 chip=0x10fb8086 > rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > class = network > subclass = ethernet > cap 01[40] = powerspec 3 supports D0 D3 current D0 > cap 05[50] = MSI supports 1 message, 64 bit, vector masks > cap 11[70] = MSI-X supports 64 messages in map 0x20 enabled > cap 10[a0] = PCI-Express 2 endpoint max data 256(512) link x8(x8) > ix2@pci0:131:0:0: class=0x020000 card=0x00038086 chip=0x10fb8086 > rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > class = network > subclass = ethernet > cap 01[40] = powerspec 3 supports D0 D3 current D0 > cap 05[50] = MSI supports 1 message, 64 bit, vector masks > cap 11[70] = MSI-X supports 64 messages in map 0x20 enabled > cap 10[a0] = PCI-Express 2 endpoint max data 256(512) link x8(x8) > ix3@pci0:131:0:1: class=0x020000 card=0x00038086 chip=0x10fb8086 > rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > class = network > subclass = ethernet > cap 01[40] = powerspec 3 supports D0 D3 current D0 > cap 05[50] = MSI supports 1 message, 64 bit, vector masks > cap 11[70] = MSI-X supports 64 messages in map 0x20 enabled > cap 10[a0] = PCI-Express 2 endpoint max data 256(512) link x8(x8) > > output of vmstat -i > > interrupt total rate > irq19: ehci0 28371 0 > irq21: uhci2 uhci4+ 48 0 > irq23: atapci0 46 0 > irq34: mpt0 146954 2 > cpu0: timer 112205297 1999 > irq256: bce0 52063 0 > irq257: bce1 1 0 > irq258: bce2 1 0 > irq259: bce3 1 0 > irq260: ix0:que 0 142258 2 > irq261: ix0:que 1 56464 1 > irq262: ix0:que 2 56199 1 > irq263: ix0:que 3 56198 1 > irq264: ix0:que 4 66569 1 > irq265: ix0:que 5 56148 1 > irq266: ix0:que 6 56217 1 > irq267: ix0:que 7 56311 1 > irq268: ix0:que 8 56169 1 > irq269: ix0:que 9 69485 1 > irq270: ix0:que 10 56176 1 > irq271: ix0:que 11 56205 1 > irq272: ix0:que 12 56281 1 > irq273: ix0:que 13 56359 1 > irq274: ix0:que 14 56292 1 > irq275: ix0:que 15 56197 1 > irq276: ix0:link 2 0 > irq277: ix1:que 0 107873 1 > irq278: ix1:que 1 56094 0 > irq279: ix1:que 2 56097 0 > irq280: ix1:que 3 56096 0 > irq281: ix1:que 4 65439 1 > irq282: ix1:que 5 56091 0 > irq283: ix1:que 6 56092 0 > irq284: ix1:que 7 56098 0 > irq285: ix1:que 8 56091 0 > irq286: ix1:que 9 56096 0 > irq287: ix1:que 10 56093 0 > irq288: ix1:que 11 56091 0 > irq289: ix1:que 12 56096 0 > irq290: ix1:que 13 56095 0 > irq291: ix1:que 14 57125 1 > irq292: ix1:que 15 56093 0 > irq293: ix1:link 1 0 > irq294: ix2:que 0 231250 4 > irq295: ix2:que 1 57784 1 > irq296: ix2:que 2 69956 1 > irq297: ix2:que 3 59498 1 > irq298: ix2:que 4 58201 1 > irq299: ix2:que 5 58599 1 > irq300: ix2:que 6 57813 1 > irq301: ix2:que 7 60075 1 > irq302: ix2:que 8 68639 1 > irq303: ix2:que 9 58194 1 > irq304: ix2:que 10 60752 1 > irq305: ix2:que 11 57628 1 > irq306: ix2:que 12 66796 1 > irq307: ix2:que 13 63307 1 > irq308: ix2:que 14 60788 1 > irq309: ix2:que 15 59102 1 > irq310: ix2:link 5 0 > irq311: ix3:que 0 56090 0 > irq312: ix3:que 1 56090 0 > irq313: ix3:que 2 56090 0 > irq314: ix3:que 3 56090 0 > irq315: ix3:que 4 56090 0 > irq316: ix3:que 5 56090 0 > irq317: ix3:que 6 56090 0 > irq318: ix3:que 7 56090 0 > irq319: ix3:que 8 56090 0 > irq320: ix3:que 9 56090 0 > irq321: ix3:que 10 56090 0 > irq322: ix3:que 11 56090 0 > irq323: ix3:que 12 56090 0 > irq324: ix3:que 13 56090 0 > irq325: ix3:que 14 56090 0 > irq326: ix3:que 15 56090 0 > cpu1: timer 112196134 1999 > cpu10: timer 112196179 1999 > cpu3: timer 112196135 1999 > cpu8: timer 112196108 1999 > cpu4: timer 112196161 1999 > cpu11: timer 112196179 1999 > cpu5: timer 112196161 1999 > cpu13: timer 112196179 1999 > cpu6: timer 112196161 1999 > cpu14: timer 112196179 1999 > cpu2: timer 112196106 1999 > cpu12: timer 112196179 1999 > cpu7: timer 112196161 1999 > cpu9: timer 112196155 1999 > cpu15: timer 112196179 1999 > Total 1799390156 32072 > > netstat -m > > 133178/4042/137220 mbufs in use (current/cache/total) > 133112/2062/135174/262144 mbuf clusters in use (current/cache/total/max) > 133112/2056 mbuf+clusters out of packet secondary zone in use > (current/cache) > 0/20/20/131072 4k (page size) jumbo clusters in use > (current/cache/total/max) > 0/0/0/65536 9k jumbo clusters in use (current/cache/total/max) > 0/0/0/32768 16k jumbo clusters in use (current/cache/total/max) > 299518K/5214K/304733K bytes allocated to network (current/cache/total) > 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) > 0/0/0 requests for jumbo clusters denied (4k/9k/16k) > 0/0/0 sfbufs in use (current/peak/max) > 0 requests for sfbufs denied > 0 requests for sfbufs delayed > 0 requests for I/O initiated by sendfile > 0 calls to protocol drain routines > > kernel config file, basically started with 64 bit and removed the stuff > I do not need. > > cpu HAMMER > ident SEEKAT > device ipmi > makeoptions DEBUG=-g # Build kernel with gdb(1) debug > symbols > options SCHED_ULE # ULE scheduler > options PREEMPTION # Enable kernel thread preemption > options INET # InterNETworking > options INET6 # IPv6 communications protocols > options SCTP # Stream Control Transmission > Protocol > options FFS # Berkeley Fast Filesystem > options SOFTUPDATES # Enable FFS soft updates support > options UFS_DIRHASH # Improve performance on big > directories > options CD9660 # ISO 9660 Filesystem > options PROCFS # Process filesystem (requires > PSEUDOFS) > options PSEUDOFS # Pseudo-filesystem framework > options GEOM_PART_GPT # GUID Partition Tables. > options GEOM_LABEL # Provides labelization > options COMPAT_43TTY # BSD 4.3 TTY compat (sgtty) > options COMPAT_IA32 # Compatible with i386 binaries > options COMPAT_FREEBSD4 # Compatible with FreeBSD4 > options COMPAT_FREEBSD5 # Compatible with FreeBSD5 > options COMPAT_FREEBSD6 # Compatible with FreeBSD6 > options COMPAT_FREEBSD7 # Compatible with FreeBSD7 > options KTRACE # ktrace(1) support > options STACK # stack(9) support > options SYSVSHM # SYSV-style shared memory > options SYSVMSG # SYSV-style message queues > options SYSVSEM # SYSV-style semaphores > options P1003_1B_SEMAPHORES # POSIX-style semaphores > options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time > extensions > options PRINTF_BUFR_SIZE=128 # Prevent printf output being > interspersed. > options KBD_INSTALL_CDEV # install a CDEV entry in /dev > options HWPMC_HOOKS # Necessary kernel hooks for > hwpmc(4) > options INCLUDE_CONFIG_FILE # Include this file in kernel > options SMP # Symmetric MultiProcessor Kernel > device cpufreq > device acpi > device pci > device ata > device atapicd # ATAPI CDROM drives > device mpt # LSI-Logic MPT-Fusion > device scbus # SCSI bus (required for SCSI) > device da # Direct Access (disks) > device pass # Passthrough device (direct SCSI access) > device atkbdc # AT keyboard controller > device atkbd # AT keyboard > device psm # PS/2 mouse > device kbdmux # keyboard multiplexer > device vga # VGA video card driver > device splash # Splash screen and screen saver support > device sc > device agp # support several AGP chipsets > device uart # Generic UART driver > device loop # Network loopback > device random # Entropy device > device ether # Ethernet support > device pty # BSD-style compatibility pseudo ttys > device bpf # Berkeley packet filter > device uhci # UHCI PCI->USB interface > device ehci # EHCI PCI->USB interface (USB 2.0) > device usb # USB Bus (required) > device uhid # "Human Interface Devices" > device ukbd # Keyboard > device umass # Disks/Mass storage - Requires scbus and > da > device ums # Mouse > > kldstat > Id Refs Address Size Name > 1 55 0xffffffff80100000 6ea290 kernel > 2 1 0xffffffff807eb000 19e088 zfs.ko > 3 2 0xffffffff8098a000 3860 opensolaris.ko > 4 2 0xffffffff8098e000 20448 krpc.ko > 5 1 0xffffffff809af000 21100 geom_mirror.ko > 6 1 0xffffffff809d1000 66c0 if_vlan.ko > 7 1 0xffffffff809d8000 506c8 if_bce.ko > 8 2 0xffffffff80a29000 3ec20 miibus.ko > 9 1 0xffffffff80a68000 243e0 if_ixgbe.ko > 10 1 0xffffffff80a8d000 1e08 coretemp.ko > > ifconfig ix2 (with -rxcsum and global addrs modified) > ix2: flags=8843 metric 0 mtu 1500 > options=5b8 > ether 00:1b:21:57:ef:7c > inet6 fe80::21b:21ff:fe57:ef7c%ix2 prefixlen 64 scopeid 0x3 > nd6 options=3 > media: Ethernet autoselect (10Gbase-SR ) > status: active > ifconfig ix2.1 > ix2.1: flags=8843 metric 0 mtu 1500 > ether 00:1b:21:57:ef:7c > inet 10.0.28.2 netmask 0xffffff00 broadcast 10.0.28.255 > inet6 fe80::21b:21ff:fe57:b420%ix2.1 prefixlen 64 scopeid 0x9 > inet6 2001:0:0:3:21b:21ff:fe57:b420 prefixlen 64 > inet6 2001:0:0:3:: prefixlen 64 anycast > nd6 options=3 > media: Ethernet autoselect (10Gbase-SR ) > status: active > vlan: 1 parent interface: ix2 > ifconfig ix2.8 > ix2.8: flags=8843 metric 0 mtu 1500 > ether 00:1b:21:57:ef:7c > inet 10.0.8.50 netmask 0xffffff00 broadcast 10.0.8.255 > inet6 fe80::21b:21ff:fe57:b420%ix2.8 prefixlen 64 scopeid 0xa > inet6 2001:0:0:1:21b:21ff:fe57:b420 prefixlen 64 > inet6 2001:0:0:1:: prefixlen 64 anycast > nd6 options=3 > media: Ethernet autoselect (10Gbase-SR ) > status: active > vlan: 8 parent interface: ix2 > > John > -- > John Hay -- jhay@meraka.csir.co.za / jhay@FreeBSD.org > From owner-freebsd-net@FreeBSD.ORG Fri Jul 23 09:35: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 4A675106566B for ; Fri, 23 Jul 2010 09:35:37 +0000 (UTC) (envelope-from grand@mindless.gr) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id DB2AE8FC08 for ; Fri, 23 Jul 2010 09:35:36 +0000 (UTC) Received: by ewy26 with SMTP id 26so1627ewy.13 for ; Fri, 23 Jul 2010 02:35:35 -0700 (PDT) Received: by 10.213.33.73 with SMTP id g9mr386267ebd.41.1279877735427; Fri, 23 Jul 2010 02:35:35 -0700 (PDT) Received: from [78.108.47.251] ([78.108.47.251]) by mx.google.com with ESMTPS id v8sm65600eeh.14.2010.07.23.02.35.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 23 Jul 2010 02:35:34 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1081) From: "Thodoris S." In-Reply-To: <4C494EC7.6080309@borsice.net> Date: Fri, 23 Jul 2010 12:35:30 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <4CFC3450-103C-4D90-A4D4-96FFDCA4510A@gmail.com> References: <403BAEC0-7D73-4584-9D4D-20B642DB938B@gmail.com> <4C494EC7.6080309@borsice.net> To: freebsd-net@freebsd.org X-Mailer: Apple Mail (2.1081) Subject: Re: FreeBSD + Quagga OSPFD issue X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2010 09:35:37 -0000 Michal Thank you very much, the second set of commands worked, route = delete and then ifconfig on the interface, is anyone have any idea on = fixing this? why FreeBSD is preferring the OSPF route instead of connected one? On Jul 23, 2010, at 11:11 AM, Michal Buchtik wrote: > Hi > we have this problem too, see bellow >=20 > On 2010/07/22 14:55, Thodoris S. wrote: >> Hello, i am experiencing a weird problem, >>=20 >> i have set up a FreeBSD 8.0 Release, with Quagga 0.9.15 running = ospfd and bgpd for a small network >> the router has multiple ethernet interfaces for backup in my case = 2.If i disconnect an ethernet either Physical or Logical (ifconfig em1 = down) >> when it comes up again after a while, Quagga doesnt use it as OSPF = interface below i am giving you some console outputs to undestand better = the issue >>=20 >> #1 show ip ospf interfaces: >> em1 is up >> ifindex 2, MTU 1500 bytes, BW 0 = Kbit >> Internet Address 10.10.32.34/30, Broadcast 10.10.32.35, Area = 0.0.0.0 >> MTU mismatch detection:enabled >> Router ID 10.10.32.39, Network Type BROADCAST, Cost: 10 >> Transmit Delay is 1 sec, State Backup, Priority 1 >> Designated Router (ID) 10.10.32.36, Interface Address 10.10.32.33 >> Backup Designated Router (ID) 10.10.32.39, Interface Address = 10.10.32.34 >> Multicast group memberships: OSPFAllRouters OSPFDesignatedRouters >> Timer intervals configured, Hello 10s, Dead 40s, Wait 40s, = Retransmit 5 >> Hello due in 0.901s >> Neighbor Count is 1, Adjacent neighbor count is 1 >>=20 >>=20 >> #2 ifconfig em1 down >> #3 ifconfig em1 up >> #4 show ip ospf interfaces: >> em1 is up >> ifindex 3, MTU 1500 bytes, BW 0 = Kbit >> OSPF not enabled on this interface >>=20 >> =20 > Check route table for prefix 10.10.32.32/30. I think, that it will be = type UG1, because quagga installed it when the interface was down (ospfd = deamon received it over another link). >> Anyone has any idea on this issue? i have searched the internet and = some people seem to have the same problem all with FreeBSD, Linux = version dosnt have this problem, some of them speaking for a patch = floating arround, but i didnt find any information on it >> i have changed the version of quagga from 0.9.15 to 0.9.16 but not = solved, i have compiled the quagga with TCP SOCKETS support but again = the problem dosnt solve, the only workaround is to reboot the whole = machine >> even if i restart quagga it doesnt work. >> =20 > Workaround is to add route manually, like this: >=20 > route delete 10.10.32.32/30; route add 10.10.32.32/30 -iface em0 > or > route delete 10.10.32.32/30; ifconfig em0 10.10.32.34/30 >=20 > I think freebsd kernel could install "connected" route when interface = goas up (and replace UG1 route) because connected could be preferred = over dynamic route. So this seems like FreeBSD bug , instead of quagga = ones. >=20 > Michal From owner-freebsd-net@FreeBSD.ORG Fri Jul 23 21:46:32 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 91A2C106566C; Fri, 23 Jul 2010 21:46:32 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 68C838FC0C; Fri, 23 Jul 2010 21:46:32 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o6NLkWhY076908; Fri, 23 Jul 2010 21:46:32 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o6NLkWTE076904; Fri, 23 Jul 2010 21:46:32 GMT (envelope-from linimon) Date: Fri, 23 Jul 2010 21:46:32 GMT Message-Id: <201007232146.o6NLkWTE076904@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/148857: [patch] [ip6] Panics due to insufficient locking in netinet6/nd6.c X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2010 21:46:32 -0000 Synopsis: [patch] [ip6] Panics due to insufficient locking in netinet6/nd6.c Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Jul 23 21:46:23 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=148857 From owner-freebsd-net@FreeBSD.ORG Fri Jul 23 21:51:20 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 10DE4106566B; Fri, 23 Jul 2010 21:51:20 +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 DC86F8FC16; Fri, 23 Jul 2010 21:51:19 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o6NLpJB1086205; Fri, 23 Jul 2010 21:51:19 GMT (envelope-from remko@freefall.freebsd.org) Received: (from remko@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o6NLpJlk086201; Fri, 23 Jul 2010 21:51:19 GMT (envelope-from remko) Date: Fri, 23 Jul 2010 21:51:19 GMT Message-Id: <201007232151.o6NLpJlk086201@freefall.freebsd.org> To: remko@FreeBSD.org, freebsd-net@FreeBSD.org, bz@FreeBSD.org From: remko@FreeBSD.org Cc: Subject: Re: kern/148857: [patch] [ip6] Panics due to insufficient locking in netinet6/nd6.c X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2010 21:51:20 -0000 Synopsis: [patch] [ip6] Panics due to insufficient locking in netinet6/nd6.c Responsible-Changed-From-To: freebsd-net->bz Responsible-Changed-By: remko Responsible-Changed-When: Fri Jul 23 21:50:40 UTC 2010 Responsible-Changed-Why: I asked Bjoern to look at this, so assign it to him. Bjoern, if you have the opportunity please look into this, thanks! http://www.freebsd.org/cgi/query-pr.cgi?pr=148857 From owner-freebsd-net@FreeBSD.ORG Sat Jul 24 12:20: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 626701065673; Sat, 24 Jul 2010 12:20:07 +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 1E49B8FC13; Sat, 24 Jul 2010 12:20:07 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 204A941C5D0; Sat, 24 Jul 2010 14:20:06 +0200 (CEST) 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 8D2V4vkD1is2; Sat, 24 Jul 2010 14:20:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id 72A4741C757; Sat, 24 Jul 2010 14:20:05 +0200 (CEST) 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 507B34448EC; Sat, 24 Jul 2010 12:17:13 +0000 (UTC) Date: Sat, 24 Jul 2010 12:17:13 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: alan yang In-Reply-To: Message-ID: <20100724121539.D57851@maildrop.int.zabbadoz.net> References: X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: interface for import/export flowtable 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, 24 Jul 2010 12:20:07 -0000 On Thu, 22 Jul 2010, alan yang wrote: Hey, > Wonder people had implemented interface to import / export flowtable. what exactly do you want to accomplish with that? -- Bjoern A. Zeeb From August on I will have a life. It's now up to you to do the maths and count to 64. -- Bondorf, Germany, 14th June 2010