From owner-freebsd-net@FreeBSD.ORG Sun Jul 22 17:55:15 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 63B72106564A for ; Sun, 22 Jul 2012 17:55:15 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 1C1878FC0A for ; Sun, 22 Jul 2012 17:55:15 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 71B0E46B0D; Sun, 22 Jul 2012 13:55:14 -0400 (EDT) Date: Sun, 22 Jul 2012 18:55:14 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Vijay Singh In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: Use of V_tcbinfo lock in tcp_do_segment() 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, 22 Jul 2012 17:55:15 -0000 On Thu, 24 May 2012, Vijay Singh wrote: > Folks, I am trying to understand the need to hold the V_tcbinfo lock in part > of this function [code included below for reference]. > > At present this causes the socket upcall to be called with the V_tcbinfo > lock held, which I'd like to avoid. We release this lock right after this > section. > > Looking at the code, it seems the lock is needed if we were in FIN_WAIT_2 > and tcp_close() the connection. The lock also seems to be protecting > V_twq_2msl. > > Would it be an acceptable solution if we deferred calling socantrecvmore() > till after the lock can be dropped (after the swtich statement). > tcp_twstart() can be changed to return tp if the connections survives, or > NULL if it doesn't, much like what tcp_close() does. Also a new lock could > be added to protect the V_rwq_2msl queue. > > If this sounds acceptable, I can generate a patch against -CURRENT. I would > appreciate feedback. Hi Vijay: Sorry for responding to your query with such a delay. A quick glance at tcp_twstart() appears to confirm your description -- I read it as requiring the incpbinfo lock for several reasons: 1) Potential call to tcp_close(). 2) Potential call to tcp_tw_2msl_scan() which may in turn call tcp_twclose(), which requires the pcbinfo lock (see 5 below). 3) Direct use of V_twq_2msl. 4) Potential call to tcp_tw_2msl_scan(), which uses V_twq_2msl, and may also call tcp_tw_close (see 5). 5) In the tcp_twclose() callgraph subtree, the pcbinfo lock is used for several things, including tcp_tw_2msl_stop() and in_pcbfree(). The call to sofree() may recurse, under some circumstances, back into pru_detach(), and then into tcp_detach() which requires the lock. Especially with the pcbgroup reworking so that the pcbhash rather than pcbinfo lock is used in a number of places, there are increasing numbers of places where this sort of optimisation could be made. One caution to ponder: socantrecvmore() can trigger an upcall (per your comment) in the receive path. It used to be that upcalls did worrying things, such as call back down the stack -- I think we've largely eliminated those (NFS UDP was one such example, now fixed?) and therefore they are probably OK, but worth checking the so_upcall consumers to see what the implications might be, if any. Robert > > -vijay > > > relevant code from tcp_do_segment(): > > if (thflags & TH_FIN) { > if (TCPS_HAVERCVDFIN(tp->t_state) == 0) { > socantrcvmore(so); > /* > * If connection is half-synchronized > * (ie NEEDSYN flag on) then delay ACK, > * so it may be piggybacked when SYN is sent. > * Otherwise, since we received a FIN then no > * more input can be expected, send ACK now. > */ > if (tp->t_flags & TF_NEEDSYN) > tp->t_flags |= TF_DELACK; > else > tp->t_flags |= TF_ACKNOW; > tp->rcv_nxt++; > } > switch (tp->t_state) { > > /* > * In SYN_RECEIVED and ESTABLISHED STATES > * enter the CLOSE_WAIT state. > */ > case TCPS_SYN_RECEIVED: > tp->t_starttime = ticks; > /* FALLTHROUGH */ > case TCPS_ESTABLISHED: > tp->t_state = TCPS_CLOSE_WAIT; > break; > > /* > * If still in FIN_WAIT_1 STATE FIN has not been acked so > * enter the CLOSING state. > */ > case TCPS_FIN_WAIT_1: > tp->t_state = TCPS_CLOSING; > break; > > /* > * In FIN_WAIT_2 state enter the TIME_WAIT state, > * starting the time-wait timer, turning off the other > * standard timers. > */ > case TCPS_FIN_WAIT_2: > INP_INFO_WLOCK_ASSERT(&V_tcbinfo); > KASSERT(ti_locked == TI_WLOCKED, ("%s: dodata " > "TCP_FIN_WAIT_2 ti_locked: %d", __func__, > ti_locked)); > > tcp_twstart(tp); > INP_INFO_WUNLOCK(&V_tcbinfo); > return; > } > _______________________________________________ > 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 Sun Jul 22 19:03:31 2012 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 BF741106564A; Sun, 22 Jul 2012 19:03:31 +0000 (UTC) (envelope-from eadler@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 9226E8FC0C; Sun, 22 Jul 2012 19:03:31 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q6MJ3VjZ033287; Sun, 22 Jul 2012 19:03:31 GMT (envelope-from eadler@freefall.freebsd.org) Received: (from eadler@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q6MJ3Vcw033283; Sun, 22 Jul 2012 19:03:31 GMT (envelope-from eadler) Date: Sun, 22 Jul 2012 19:03:31 GMT Message-Id: <201207221903.q6MJ3Vcw033283@freefall.freebsd.org> To: eadler@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: eadler@FreeBSD.org Cc: Subject: Re: kern/170070: [regression] 9.1-PRERELEASE host cannot talk to itself over IPv6 (except on loopback) 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, 22 Jul 2012 19:03:31 -0000 Old Synopsis: 9.1-PRERELEASE host cannot talk to itself over IPv6 (except on loopback) New Synopsis: [regression] 9.1-PRERELEASE host cannot talk to itself over IPv6 (except on loopback) Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: eadler Responsible-Changed-When: Sun Jul 22 19:03:04 UTC 2012 Responsible-Changed-Why: change synopsis and assign http://www.freebsd.org/cgi/query-pr.cgi?pr=170070 From owner-freebsd-net@FreeBSD.ORG Sun Jul 22 20:33:55 2012 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 39B4A1065672; Sun, 22 Jul 2012 20:33:55 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 0C85A8FC0C; Sun, 22 Jul 2012 20:33:55 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q6MKXskX046439; Sun, 22 Jul 2012 20:33:54 GMT (envelope-from bz@freefall.freebsd.org) Received: (from bz@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q6MKXsmb046435; Sun, 22 Jul 2012 20:33:54 GMT (envelope-from bz) Date: Sun, 22 Jul 2012 20:33:54 GMT Message-Id: <201207222033.q6MKXsmb046435@freefall.freebsd.org> To: bz@FreeBSD.org, freebsd-net@FreeBSD.org, bz@FreeBSD.org From: bz@FreeBSD.org Cc: Subject: Re: kern/170070: [regression] 9.1-PRERELEASE host cannot talk to itself over IPv6 (except on loopback) 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, 22 Jul 2012 20:33:55 -0000 Synopsis: [regression] 9.1-PRERELEASE host cannot talk to itself over IPv6 (except on loopback) Responsible-Changed-From-To: freebsd-net->bz Responsible-Changed-By: bz Responsible-Changed-When: Sun Jul 22 20:33:04 UTC 2012 Responsible-Changed-Why: Claim. I am working on the bugfix. http://www.freebsd.org/cgi/query-pr.cgi?pr=170070 From owner-freebsd-net@FreeBSD.ORG Sun Jul 22 20:41:42 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A48051065670; Sun, 22 Jul 2012 20:41:42 +0000 (UTC) (envelope-from trociny@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 778AB8FC0C; Sun, 22 Jul 2012 20:41:42 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q6MKfgc0057271; Sun, 22 Jul 2012 20:41:42 GMT (envelope-from trociny@freefall.freebsd.org) Received: (from trociny@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q6MKfg6U057267; Sun, 22 Jul 2012 20:41:42 GMT (envelope-from trociny) Date: Sun, 22 Jul 2012 20:41:42 GMT Message-Id: <201207222041.q6MKfg6U057267@freefall.freebsd.org> To: trociny@FreeBSD.org, freebsd-net@FreeBSD.org, freebsd-virtualization@FreeBSD.org From: trociny@FreeBSD.org Cc: Subject: Re: kern/169991: [if_run] [vimage] panic after device plugged in 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, 22 Jul 2012 20:41:42 -0000 Synopsis: [if_run] [vimage] panic after device plugged in Responsible-Changed-From-To: freebsd-net->freebsd-virtualization Responsible-Changed-By: trociny Responsible-Changed-When: Sun Jul 22 20:39:48 UTC 2012 Responsible-Changed-Why: VIMAGE related. http://www.freebsd.org/cgi/query-pr.cgi?pr=169991 From owner-freebsd-net@FreeBSD.ORG Mon Jul 23 10:10:49 2012 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 87849106566B; Mon, 23 Jul 2012 10:10:49 +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 596D18FC0A; Mon, 23 Jul 2012 10:10:49 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q6NAAnxk081892; Mon, 23 Jul 2012 10:10:49 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q6NAAnoE081888; Mon, 23 Jul 2012 10:10:49 GMT (envelope-from linimon) Date: Mon, 23 Jul 2012 10:10:49 GMT Message-Id: <201207231010.q6NAAnoE081888@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/170081: [fxp] pf/nat/jails not working if checksum offloading is enabled on fxp0 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, 23 Jul 2012 10:10:49 -0000 Old Synopsis: pf/nat/jails not working if checksum offloading is enabled on fxp0 New Synopsis: [fxp] pf/nat/jails not working if checksum offloading is enabled on fxp0 Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Jul 23 10:10:30 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=170081 From owner-freebsd-net@FreeBSD.ORG Mon Jul 23 11:07:21 2012 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 4F51B1065673 for ; Mon, 23 Jul 2012 11:07:21 +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 37B8A8FC20 for ; Mon, 23 Jul 2012 11:07:21 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q6NB7LWL090098 for ; Mon, 23 Jul 2012 11:07:21 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q6NB7KR9090096 for freebsd-net@FreeBSD.org; Mon, 23 Jul 2012 11:07:20 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 23 Jul 2012 11:07:20 GMT Message-Id: <201207231107.q6NB7KR9090096@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, 23 Jul 2012 11:07:21 -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/170081 net [fxp] pf/nat/jails not working if checksum offloading o kern/169898 net ifconfig(8) fails to set MTU on multiple interfaces. o kern/169676 net [bge] [hang] system hangs, fully or partially after re o kern/169664 net [bgp] Wrongful replacement of interface connected net o kern/169634 net [bge] Network unavailable when booting directly to Fre o kern/169620 net [ng] [pf] ng_l2tp incoming packet bypass pf firewall o kern/169459 net [ppp] umodem/ppp/3g stopped working after update from o kern/169438 net [ipsec] ipv4-in-ipv6 tunnel mode IPsec does not work o kern/169399 net [re] RealTek RTL8168/8111/8111c network interface not p kern/168294 net [ixgbe] [patch] ixgbe driver compiled in kernel has no o kern/168246 net [em] Multiple em(4) not working with qemu o kern/168245 net [arp] [regression] Permanent ARP entry not deleted on o kern/168244 net [arp] [regression] Unable to manually remove permanent o kern/168183 net [bce] bce driver hang system o kern/168152 net [xl] Periodically, the network card xl0 stops working o kern/167947 net [setfib] [patch] arpresolve checks only the default FI o kern/167603 net [ip] IP fragment reassembly's broken: file transfer ov o kern/167500 net [em] [panic] Kernel panics in em driver o kern/167325 net [netinet] [patch] sosend sometimes return EINVAL with o kern/167202 net [igmp]: Sending multiple IGMP packets crashes kernel o kern/167059 net [tcp] [panic] System does panic in in_pcbbind() and ha o kern/166940 net [ipfilter] [panic] Double fault in kern 8.2 o kern/166462 net [gre] gre(4) when using a tunnel source address from c o kern/166372 net [patch] ipfilter drops UDP packets with zero checksum o kern/166285 net [arp] FreeBSD v8.1 REL p8 arp: unknown hardware addres o kern/166255 net [net] [patch] It should be possible to disable "promis o kern/165963 net [panic] [ipf] ipfilter/nat NULL pointer deference o kern/165903 net mbuf leak o kern/165863 net [panic] [netinet] [patch] in_lltable_prefix_free() rac o kern/165643 net [net] [patch] Missing vnet restores in net/if_ethersub o kern/165622 net [ndis][panic][patch] Unregistered use of FPU in kernel s kern/165562 net [request] add support for Intel i350 in FreeBSD 7.4 o kern/165526 net [bxe] UDP packets checksum calculation whithin if_bxe o kern/165488 net [ppp] [panic] Fatal trap 12 jails and ppp , kernel wit o kern/165305 net [ip6] [request] Feature parity between IP_TOS and IPV6 o kern/165296 net [vlan] [patch] Fix EVL_APPLY_VLID, update EVL_APPLY_PR o kern/165181 net [igb] igb freezes after about 2 weeks of uptime o kern/165174 net [patch] [tap] allow tap(4) to keep its address on clos o kern/165152 net [ip6] Does not work through the issue of ipv6 addresse o kern/164495 net [igb] connect double head igb to switch cause system t o kern/164490 net [pfil] Incorrect IP checksum on pfil pass from ip_outp o kern/164475 net [gre] gre misses RUNNING flag after a reboot o kern/164265 net [netinet] [patch] tcp_lro_rx computes wrong checksum i o kern/163903 net [igb] "igb0:tx(0)","bpf interface lock" v2.2.5 9-STABL o kern/163481 net freebsd do not add itself to ping route packet o kern/162927 net [tun] Modem-PPP error ppp[1538]: tun0: Phase: Clearing o kern/162926 net [ipfilter] Infinite loop in ipfilter with fragmented I o kern/162558 net [dummynet] [panic] seldom dummynet panics o kern/162153 net [em] intel em driver 7.2.4 don't compile o kern/162110 net [igb] [panic] RELENG_9 panics on boot in IGB driver - o kern/162028 net [ixgbe] [patch] misplaced #endif in ixgbe.c o kern/161381 net [re] RTL8169SC - re0: PHY write failed o kern/161277 net [em] [patch] BMC cannot receive IPMI traffic after loa o kern/160873 net [igb] igb(4) from HEAD fails to build on 7-STABLE o kern/160750 net Intel PRO/1000 connection breaks under load until rebo o kern/160693 net [gif] [em] Multicast packet are not passed from GIF0 t o kern/160293 net [ieee80211] ppanic] kernel panic during network setup o kern/160206 net [gif] gifX stops working after a while (IPv6 tunnel) o kern/159817 net [udp] write UDPv4: No buffer space available (code=55) o kern/159629 net [ipsec] [panic] kernel panic with IPsec in transport m o kern/159621 net [tcp] [panic] panic: soabort: so_count o kern/159603 net [netinet] [patch] in_ifscrubprefix() - network route c o kern/159601 net [netinet] [patch] in_scrubprefix() - loopback route re o kern/159294 net [em] em watchdog timeouts o kern/159203 net [wpi] Intel 3945ABG Wireless LAN not support IBSS o kern/158930 net [bpf] BPF element leak in ifp->bpf_if->bif_dlist o kern/158726 net [ip6] [patch] ICMPv6 Router Announcement flooding limi o kern/158694 net [ix] [lagg] ix0 is not working within lagg(4) o kern/158665 net [ip6] [panic] kernel pagefault in in6_setscope() o kern/158635 net [em] TSO breaks BPF packet captures with em driver f kern/157802 net [dummynet] [panic] kernel panic in dummynet o kern/157785 net amd64 + jail + ipfw + natd = very slow outbound traffi o kern/157418 net [em] em driver lockup during boot on Supermicro X9SCM- o kern/157410 net [ip6] IPv6 Router Advertisements Cause Excessive CPU U o kern/157287 net [re] [panic] INVARIANTS panic (Memory modified after f o kern/157209 net [ip6] [patch] locking error in rip6_input() (sys/netin o kern/157200 net [network.subr] [patch] stf(4) can not communicate betw o kern/157182 net [lagg] lagg interface not working together with epair o kern/156877 net [dummynet] [panic] dummynet move_pkt() null ptr derefe o kern/156667 net [em] em0 fails to init on CURRENT after March 17 o kern/156408 net [vlan] Routing failure when using VLANs vs. Physical e o kern/156328 net [icmp]: host can ping other subnet but no have IP from o kern/156317 net [ip6] Wrong order of IPv6 NS DAD/MLD Report o kern/156283 net [ip6] [patch] nd6_ns_input - rtalloc_mpath does not re o kern/156279 net [if_bridge][divert][ipfw] unable to correctly re-injec o kern/156226 net [lagg]: failover does not announce the failover to swi o kern/156030 net [ip6] [panic] Crash in nd6_dad_start() due to null ptr o kern/155772 net ifconfig(8): ioctl (SIOCAIFADDR): File exists on direc o kern/155680 net [multicast] problems with multicast s kern/155642 net [request] Add driver for Realtek RTL8191SE/RTL8192SE W o kern/155597 net [panic] Kernel panics with "sbdrop" message o kern/155420 net [vlan] adding vlan break existent vlan o kern/155177 net [route] [panic] Panic when inject routes in kernel o kern/155030 net [igb] igb(4) DEVICE_POLLING does not work with carp(4) o kern/155010 net [msk] ntfs-3g via iscsi using msk driver cause kernel o kern/154943 net [gif] ifconfig gifX create on existing gifX clears IP s kern/154851 net [request]: Port brcm80211 driver from Linux to FreeBSD o kern/154850 net [netgraph] [patch] ng_ether fails to name nodes when t o kern/154679 net [em] Fatal trap 12: "em1 taskq" only at startup (8.1-R o kern/154600 net [tcp] [panic] Random kernel panics on tcp_output o kern/154557 net [tcp] Freeze tcp-session of the clients, if in the gat o kern/154443 net [if_bridge] Kernel module bridgestp.ko missing after u o kern/154286 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/154255 net [nfs] NFS not responding o kern/154214 net [stf] [panic] Panic when creating stf interface o kern/154185 net race condition in mb_dupcl o kern/154169 net [multicast] [ip6] Node Information Query multicast add o kern/154134 net [ip6] stuck kernel state in LISTEN on ipv6 daemon whic o kern/154091 net [netgraph] [panic] netgraph, unaligned mbuf? o conf/154062 net [vlan] [patch] change to way of auto-generatation of v o kern/153937 net [ral] ralink panics the system (amd64 freeBSDD 8.X) wh o kern/153936 net [ixgbe] [patch] MPRC workaround incorrectly applied to o kern/153816 net [ixgbe] ixgbe doesn't work properly with the Intel 10g o kern/153772 net [ixgbe] [patch] sysctls reference wrong XON/XOFF varia o kern/153497 net [netgraph] netgraph panic due to race conditions o kern/153454 net [patch] [wlan] [urtw] Support ad-hoc and hostap modes o kern/153308 net [em] em interface use 100% cpu o kern/153244 net [em] em(4) fails to send UDP to port 0xffff o kern/152893 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/152853 net [em] tftpd (and likely other udp traffic) fails over e o kern/152828 net [em] poor performance on 8.1, 8.2-PRE o kern/152569 net [net]: Multiple ppp connections and routing table prob o kern/152235 net [arp] Permanent local ARP entries are not properly upd o kern/152141 net [vlan] [patch] encapsulate vlan in ng_ether before out o kern/152036 net [libc] getifaddrs(3) returns truncated sockaddrs for n o kern/151690 net [ep] network connectivity won't work until dhclient is o kern/151681 net [nfs] NFS mount via IPv6 leads to hang on client with o kern/151593 net [igb] [panic] Kernel panic when bringing up igb networ o kern/150920 net [ixgbe][igb] Panic when packets are dropped with heade o kern/150557 net [igb] igb0: Watchdog timeout -- resetting o kern/150251 net [patch] [ixgbe] Late cable insertion broken o kern/150249 net [ixgbe] Media type detection broken o bin/150224 net ppp(8) does not reassign static IP after kill -KILL co f kern/149969 net [wlan] [ral] ralink rt2661 fails to maintain connectio o kern/149937 net [ipfilter] [patch] kernel panic in ipfilter IP fragmen o kern/149643 net [rum] device not sending proper beacon frames in ap mo o kern/149609 net [panic] reboot after adding second default route o kern/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148018 net [flowtable] flowtable crashes on ia64 o kern/147912 net [boot] FreeBSD 8 Beta won't boot on Thinkpad i1300 11 o kern/147894 net [ipsec] IPv6-in-IPv4 does not work inside an ESP-only o kern/147155 net [ip6] setfb not work with ipv6 o kern/146845 net [libc] close(2) returns error 54 (connection reset by f kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146534 net [icmp6] wrong source address in echo reply o kern/146427 net [mwl] Additional virtual access points don't work on m 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/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/145825 net [panic] panic: soabort: so_count o kern/145728 net [lagg] Stops working lagg between two servers. p kern/145600 net TCP/ECN behaves different to CE/CWR than ns2 reference f kern/144917 net [flowtable] [panic] flowtable crashes system [regressi 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 conf/144700 net [rc.d] async dhclient breaks stuff for too many people o kern/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/144231 net bind/connect/sendto too strict about sockaddr length 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/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/143208 net [ipsec] [gif] IPSec over gif interface not working o kern/143034 net [panic] system reboots itself in tcp code [regression] 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 f kern/142518 net [em] [lagg] Problem on 8.0-STABLE with em and lagg 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 f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140682 net [netgraph] [panic] random panic in netgraph 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/140346 net [wlan] High bandwidth use causes loss of wlan connecti 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/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 p kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139117 net [lagg] + wlan boot timing (EBUSY) 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/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/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 f kern/138029 net [bpf] [panic] periodically kernel panic and reboot o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 p bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i 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/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/135502 net [periodic] Warning message raised by rtfree function i 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/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133736 net [udp] ip_id not protected ... 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 f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o conf/132851 net [patch] rc.conf(5): allow to setfib(1) for service run o kern/132734 net [ifmib] [panic] panic in net/if_mib.c 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/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/132277 net [crypto] [ipsec] poor performance using cryptodevice f 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 kern/131601 net [ipfilter] [panic] 7-STABLE panic in nat_finalise (tcp o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o bin/131365 net route(8): route add changes interpretation of network 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 f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow f kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat 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 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 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/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 p kern/127360 net [socket] TOE socket options missing from sosetopt() 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/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126339 net [ipw] ipw driver drops the connection 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/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre 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. 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 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 conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c 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 f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge 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/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 s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net 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/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/120966 net [rum] kernel panic with if_rum and WPA encryption 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 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 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 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/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/111537 net [inet6] [patch] ip6_input() treats mbuf cluster wrong o kern/111457 net [ral] ral(4) freeze o kern/110284 net [if_ethersubr] Invalid Assumption in SIOCSIFADDR in et o kern/110249 net [kernel] [regression] [patch] setsockopt() error regre o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] 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/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/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 o kern/97306 net [netgraph] NG_L2TP locks after connection with failed o conf/97014 net [gif] gifconfig_gif? in rc.conf does not recognize IPv f kern/96268 net [socket] TCP socket performance drops by 3000% if pack 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 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 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/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87421 net [netgraph] [panic]: ng_ether + ng_eiface + if_bridge 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 p kern/85320 net [gre] [patch] possible depletion of kernel stack in ip 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 kern/82468 net Using 64MB tcp send/recv buffers, trafficflow stops, i o bin/82185 net [patch] ndp(8) can delete the incorrect entry o kern/81095 net IPsec connection stops working if associated network i 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 o kern/77341 net [ip6] problems with IPV6 implementation 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 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/68889 net [panic] m_copym, length > size of mbuf chain 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 s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31940 net ip queue length too short for >500kpps 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 f kern/24959 net [patch] proper TCP_NOPUSH/TCP_CORK compatibility o conf/23063 net [arp] [patch] for static ARP tables in rc.network o kern/21998 net [socket] [patch] ident only for outgoing connections o kern/5877 net [socket] sb_cc counts control data as well as data dat 412 problems total. From owner-freebsd-net@FreeBSD.ORG Tue Jul 24 18:18:29 2012 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 5DFE21065678; Tue, 24 Jul 2012 18:18:29 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id BCB328FC17; Tue, 24 Jul 2012 18:18:28 +0000 (UTC) Received: by weyx56 with SMTP id x56so6393104wey.13 for ; Tue, 24 Jul 2012 11:18:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=5yPXMt57VKKDGr2n4lrETE0gqk+WFMPKx9D932NKZoM=; b=JaGAzk7/LdBaVT0OdN8HwxNHjHu3ufducSkjyYwjKqqL7nP129agDNbcb8Y2vmtGwG d2vQ1nLKlgS6WOL/AckdP7FjRdrzo3Io6RIhgAAkaIJMTC8GHwpGYGval8hdYqOo7LTr ugEgKq+Gs3m6aWlfH6DdhJ9G04MZ043/ao6LqK5r/cPCA48vTVYodm1g/pW7JeWLAaxP HfCE7tyh1sJn+jaLWhzYWco+qDNR3JP3kYTM143XGwGLtxempiU1hRFmRUluRpLQi3fp ynkRyIJdUgNtU9XwT012l844Wq4C5BF2tIHnduK/S4BTkO1fHZ+GY5C7SiTIBSkh+ZPc WuUA== MIME-Version: 1.0 Received: by 10.180.78.33 with SMTP id y1mr9232694wiw.3.1343153907921; Tue, 24 Jul 2012 11:18:27 -0700 (PDT) Received: by 10.216.79.81 with HTTP; Tue, 24 Jul 2012 11:18:27 -0700 (PDT) Date: Tue, 24 Jul 2012 14:18:27 -0400 Message-ID: From: Arnaud Lacombe To: FreeBSD Net Content-Type: multipart/mixed; boundary=f46d043bdec88f754c04c5976376 Cc: FreeBSD Hackers Subject: Generic queue's KPI to manipulate mbuf's queue 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, 24 Jul 2012 18:18:29 -0000 --f46d043bdec88f754c04c5976376 Content-Type: text/plain; charset=ISO-8859-1 Hi, AFAIK, there is no proper KPI for managing mbuf queue. All users have to re-implements the queue logic from scratch, which is less than optimal. From a preeminent FreeBSD developer at BSDCan 2009: "we do not need a new list implementation". There has been a few attempt of providing a queue API, namely , but that is nothing more than an ad-hoc solution to something which _has_to_be_ generic. For the sake of adding more mess in the tree, this implementation has been duplicated in ... Now, I understand, or at least merely witness without power, the reluctance of kernel hackers to have 'struct mbuf` evolves, especially wrt. their desire to keep binary compatibility of KPI[0]. Now, none of the current ad-hoc API matched my needs, and I really did NOT want to re-implement a new list implementation for missing basic operation, such as deleting an element of the list, so I came with the attached patch. The main idea is to be able to use already existing code from for mbuf queuing management. It is not the best which can be done. I am not a huge fan of keeping `m_nextpkt' and introducing a `m_nextelm', I would have preferred to use TAILQs, and I do not like the dwelling in SLIST internal implementation details. However, this change is relatively lightweight, and change neither ABI or API. Any comment appreciated. - Arnaud [0]: taking care of having a stable kernel ABI and *not* a stable userland ABI is beyond my understanding, but this is not the subject of this mail. --f46d043bdec88f754c04c5976376 Content-Type: application/octet-stream; name="mbuf_slist.diff" Content-Disposition: attachment; filename="mbuf_slist.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h51aq8mx0 ZGlmZiAtLWdpdCBhL2ZyZWVic2Qvc3lzL3N5cy9tYnVmLmggYi9mcmVlYnNkL3N5cy9zeXMvbWJ1 Zi5oCmluZGV4IDkwN2I3N2EuLmVhOWFmZWIgMTAwNjQ0Ci0tLSBhL3N5cy9zeXMvbWJ1Zi5oCisr KyBiL3N5cy9zeXMvbWJ1Zi5oCkBAIC04OCw3ICs4OCw3IEBAIHN0cnVjdCBtYl9hcmdzIHsKICAq Lwogc3RydWN0IG1faGRyIHsKIAlzdHJ1Y3QgbWJ1ZgkqbWhfbmV4dDsJLyogbmV4dCBidWZmZXIg aW4gY2hhaW4gKi8KLQlzdHJ1Y3QgbWJ1ZgkqbWhfbmV4dHBrdDsJLyogbmV4dCBjaGFpbiBpbiBx dWV1ZS9yZWNvcmQgKi8KKwlTTElTVF9FTlRSWShtYnVmKSBtaF9uZXh0cGt0OwkvKiBuZXh0IGNo YWluIGluIHF1ZXVlL3JlY29yZCAqLwogCWNhZGRyX3QJCSBtaF9kYXRhOwkvKiBsb2NhdGlvbiBv ZiBkYXRhICovCiAJaW50CQkgbWhfbGVuOwkvKiBhbW91bnQgb2YgZGF0YSBpbiB0aGlzIG1idWYg Ki8KIAlpbnQJCSBtaF9mbGFnczsJLyogZmxhZ3M7IHNlZSBiZWxvdyAqLwpAQCAtMTU5LDcgKzE1 OSw4IEBAIHN0cnVjdCBtYnVmIHsKICNkZWZpbmUJbV9kYXRhCQltX2hkci5taF9kYXRhCiAjZGVm aW5lCW1fdHlwZQkJbV9oZHIubWhfdHlwZQogI2RlZmluZQltX2ZsYWdzCQltX2hkci5taF9mbGFn cwotI2RlZmluZQltX25leHRwa3QJbV9oZHIubWhfbmV4dHBrdAorI2RlZmluZQltX25leHRwa3QJ bV9oZHIubWhfbmV4dHBrdC5zbGVfbmV4dAorI2RlZmluZQltX25leHRlbG0JbV9oZHIubWhfbmV4 dHBrdAogI2RlZmluZQltX2FjdAkJbV9uZXh0cGt0CiAjZGVmaW5lCW1fcGt0aGRyCU1fZGF0Lk1I Lk1IX3BrdGhkcgogI2RlZmluZQltX2V4dAkJTV9kYXQuTUguTUhfZGF0Lk1IX2V4dAo= --f46d043bdec88f754c04c5976376-- From owner-freebsd-net@FreeBSD.ORG Tue Jul 24 20:25:53 2012 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 ED414106566B for ; Tue, 24 Jul 2012 20:25:52 +0000 (UTC) (envelope-from ming.fu@netsweeper.com) Received: from mail.netsweeper.com (mail.netsweeper.com [216.171.98.87]) by mx1.freebsd.org (Postfix) with ESMTP id BCDCB8FC08 for ; Tue, 24 Jul 2012 20:25:52 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.netsweeper.com (Postfix) with ESMTP id BAC1AC2002A for ; Tue, 24 Jul 2012 16:19:33 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.netsweeper.com Received: from mail.netsweeper.com ([127.0.0.1]) by localhost (mail.netsweeper.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9sfhzUf0E7sg for ; Tue, 24 Jul 2012 16:19:33 -0400 (EDT) Received: from [192.168.4.199] (unknown [216.171.98.93]) by mail.netsweeper.com (Postfix) with ESMTPSA id 2FC6BC20029 for ; Tue, 24 Jul 2012 16:19:33 -0400 (EDT) Message-ID: <500F034F.6040809@netsweeper.com> Date: Tue, 24 Jul 2012 16:19:27 -0400 From: Ming Fu User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: netmap bridge.c sample code assumes the same number of tx/rx queue. 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, 24 Jul 2012 20:25:53 -0000 Hi Everybody, I just want to share some work I was doing last few days trying to make use the bridge code of netmap. My netmap device has 4 receive and 1 transmit queue. I found that a ping -s 5100 10.10.10.10 through the bridge will lost fragment of the ping when the transmit queue reaches its wrapping point (the last slot). The problem was traced to the code in tools/tools/netmap/bridge.c. It assumes the same number of receive and transmit queues from the netmap device, which does not work for me. The number of queues is stored in struct my_ring when the netmap device is opened, but only the number of receive queue is saved. Subsequent code uses the number of receive queues to check of bond of transmit queues. When the transmit queue is less than the receive queue, the bridge program will start to loose packet when the queue wraps happens at the last transmit queue. Regards, Ming From owner-freebsd-net@FreeBSD.ORG Tue Jul 24 23:08:34 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 95F64106564A for ; Tue, 24 Jul 2012 23:08:34 +0000 (UTC) (envelope-from philipp_subx@redfish-solutions.com) Received: from mail.redfish-solutions.com (mail.redfish-solutions.com [66.232.79.143]) by mx1.freebsd.org (Postfix) with ESMTP id 555258FC0A for ; Tue, 24 Jul 2012 23:08:34 +0000 (UTC) Received: from macbook.redfish-solutions.com ([192.168.1.17]) (authenticated bits=0) by mail.redfish-solutions.com (8.14.5/8.14.5) with ESMTP id q6OMstOH006102 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 24 Jul 2012 16:54:56 -0600 Message-ID: <500F27BF.40802@redfish-solutions.com> Date: Tue, 24 Jul 2012 16:54:55 -0600 From: Philip Prindeville User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120625 Thunderbird/15.0a2 MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.73 on 192.168.1.3 Subject: Mapping from rtm_flags back to MIB IANAipRouteProtocol value 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, 24 Jul 2012 23:08:34 -0000 Ok, dumb question... How do I map a routing entries rtm_flags back to a IANAipRouteProtocol value? From owner-freebsd-net@FreeBSD.ORG Wed Jul 25 08:06:44 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 06E76106564A for ; Wed, 25 Jul 2012 08:06:44 +0000 (UTC) (envelope-from melifaro@FreeBSD.org) Received: from mail.ipfw.ru (unknown [IPv6:2a01:4f8:120:6141::2]) by mx1.freebsd.org (Postfix) with ESMTP id 948DA8FC0C for ; Wed, 25 Jul 2012 08:06:43 +0000 (UTC) Received: from secured.by.ipfw.ru ([95.143.220.47] helo=ws.su29.net) by mail.ipfw.ru with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1Stweu-0006l8-Qw; Wed, 25 Jul 2012 12:09:28 +0400 Message-ID: <500FA90D.9060209@FreeBSD.org> Date: Wed, 25 Jul 2012 12:06:37 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120121 Thunderbird/9.0 MIME-Version: 1.0 To: Philip Prindeville References: <500F27BF.40802@redfish-solutions.com> In-Reply-To: <500F27BF.40802@redfish-solutions.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Mapping from rtm_flags back to MIB IANAipRouteProtocol value 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, 25 Jul 2012 08:06:44 -0000 On 25.07.2012 02:54, Philip Prindeville wrote: > Ok, dumb question... How do I map a routing entries rtm_flags back to a IANAipRouteProtocol value? Well, something like this can probably be used: ~RTF_GATEWAY maps to local (2), -- local interface RTF_STATIC maps to netmgmt (3), -- static route RTF_DYNAMIC maps to icmp (4), -- result of ICMP Redirect other routes? other (1), -- not specified RTF_PROTO1 tells us thet it is dynamic route, and you have to use quagga/bird/openbgpd/whatever cli / api to get more precise results. You can examine `netstat -rn -finet` output with netstat(8) to get good overview for common route types. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Wed Jul 25 08:47:18 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3A952106566B for ; Wed, 25 Jul 2012 08:47:18 +0000 (UTC) (envelope-from mah.s.369@gmail.com) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id E8E918FC0A for ; Wed, 25 Jul 2012 08:47:17 +0000 (UTC) Received: by qcsg15 with SMTP id g15so292257qcs.13 for ; Wed, 25 Jul 2012 01:47:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=sreFPzk4Fh5SeACG2rt/yYgRixSnirh9FYHPfLEIQ/c=; b=i3keLAqJPjkq3DkSPkw4B44MV46gtZ+vvEwmgjkhVSkRZHOOFcjyz5TM28kpURejBQ dS+zRBIpyuAflgET7T6wUjm4sHGrvmRII34p2JlmMUL/4okyEyZFc7xW9bHyX9WbXLXB BzCnBHtCG2ZbbGl6g/5igeuqmAh/U6ujei/m3IOTMoTZ5Gnslt+EQPygRmQuXTsK4oLQ aoa7NsTAJPw/d6THCdpAPolmno8P/PGnNo4xs4MzxDnu1vm/jtf94G/Hk6ewfXSIXSfd DNfZRcyfUdAlQfxODldTf8qGQ6bJykYbR+G6x+72Axuc8YVBynzvrWmRZ7ICPVkiMwwL 38AA== MIME-Version: 1.0 Received: by 10.229.137.66 with SMTP id v2mr171626qct.41.1343206031147; Wed, 25 Jul 2012 01:47:11 -0700 (PDT) Received: by 10.49.86.196 with HTTP; Wed, 25 Jul 2012 01:47:11 -0700 (PDT) Date: Wed, 25 Jul 2012 01:47:11 -0700 Message-ID: From: m s To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Enable/Disable flow control in FreeBSD X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 08:47:18 -0000 Hi all. I want to disbale flow control on network interfaces.I must do a test and I can't because flow control in enable.Is it enable as default?How I can disable it? Thanks From owner-freebsd-net@FreeBSD.ORG Wed Jul 25 09:19:36 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B4F2B1065670 for ; Wed, 25 Jul 2012 09:19:36 +0000 (UTC) (envelope-from mah.s.369@gmail.com) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 710CB8FC14 for ; Wed, 25 Jul 2012 09:19:36 +0000 (UTC) Received: by qcsg15 with SMTP id g15so305737qcs.13 for ; Wed, 25 Jul 2012 02:19:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=6g1xDL8wMn/cdkyRBCrqMprzatb0Wotg7HXbsBs5ZGg=; b=iA8GpgJBZwH25KrMSJes5i6PcJzfJsf1oCQeTUOUzrlrD/bePap8qmn7VNfvT7RHfq Z4ZXW+7iI6kpm87Du29qd+XTS8bBdlnvznf11WMrWAZFqOPFpA7XQhvo7fbOGslxgtd4 KkLfjGKJc/KJU/FwZYqzG6xrYI3iJHvFBoXSnp76eLAeDoaloPxcIN1fsdi7MW31uZi2 z+jDuGphwB/bymHOcrPkB/Wu1PNEYj+r3dHkKrzlhYw3syorryNFGIZcWlABUB6Opxvy 0DcjLH4vWrbs1ugI5R/ClCzia+7MmPXVHkQvdEGBJZlSWxCrXJqfIS2mPNZd/AILUTT3 0hhg== MIME-Version: 1.0 Received: by 10.229.134.206 with SMTP id k14mr10772565qct.25.1343207975885; Wed, 25 Jul 2012 02:19:35 -0700 (PDT) Received: by 10.49.86.196 with HTTP; Wed, 25 Jul 2012 02:19:35 -0700 (PDT) Date: Wed, 25 Jul 2012 02:19:35 -0700 Message-ID: From: m s To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: enable/disable flow control in freebsd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 09:19:36 -0000 Hi all. I want to disbale flow control on network interfaces.I must do a test and I can't because flow control in enable.Is it enable as default?How I can disable it? Thanks From owner-freebsd-net@FreeBSD.ORG Wed Jul 25 11:32:33 2012 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 2A3B3106564A for ; Wed, 25 Jul 2012 11:32:33 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 898EF8FC08 for ; Wed, 25 Jul 2012 11:32:32 +0000 (UTC) Received: (qmail 83650 invoked from network); 25 Jul 2012 13:20:14 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 25 Jul 2012 13:20:14 -0000 Message-ID: <500FD7B9.4070804@freebsd.org> Date: Wed, 25 Jul 2012 13:25:45 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Arnaud Lacombe References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net , FreeBSD Hackers Subject: Re: Generic queue's KPI to manipulate mbuf's queue 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, 25 Jul 2012 11:32:33 -0000 On 24.07.2012 20:18, Arnaud Lacombe wrote: > Hi, > > AFAIK, there is no proper KPI for managing mbuf queue. All users have Before we can talk about an mbuf queue you have to define what you want to "queue". Is it packets or an mbuf chain which doesn't have clear delimiters (as with tcp for example)? Depending on that the requirements and solutions may be vastly different. > to re-implements the queue logic from scratch, which is less than > optimal. From a preeminent FreeBSD developer at BSDCan 2009: "we do > not need a new list implementation". There has been a few attempt of > providing a queue API, namely , but that is > nothing more than an ad-hoc solution to something which _has_to_be_ > generic. For the sake of adding more mess in the tree, this > implementation has been duplicated in ... Duplication is always a sign for the need of a generic approach/KPI. > Now, I understand, or at least merely witness without power, the > reluctance of kernel hackers to have 'struct mbuf` evolves, especially > wrt. their desire to keep binary compatibility of KPI[0]. Now, none of > the current ad-hoc API matched my needs, and I really did NOT want to > re-implement a new list implementation for missing basic operation, > such as deleting an element of the list, so I came with the attached > patch. The main idea is to be able to use already existing code from > for mbuf queuing management. It is not the best which > can be done. I am not a huge fan of keeping `m_nextpkt' and > introducing a `m_nextelm', I would have preferred to use TAILQs, and I > do not like the dwelling in SLIST internal implementation details. > However, this change is relatively lightweight, and change neither ABI > or API. IMO your change is a rather elegant way of introducing the LIST macros to the mbuf nextpkt field. I do like it and don't object to it providing you sufficiently answer the question in the first paragraph. -- Andre > Any comment appreciated. > > - Arnaud > > [0]: taking care of having a stable kernel ABI and *not* a stable > userland ABI is beyond my understanding, but this is not the subject > of this mail. > > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Wed Jul 25 13:04:08 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B0F40106564A for ; Wed, 25 Jul 2012 13:04:08 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 401A68FC19 for ; Wed, 25 Jul 2012 13:04:08 +0000 (UTC) Received: by wgbds11 with SMTP id ds11so670804wgb.31 for ; Wed, 25 Jul 2012 06:04:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=261FynTAHkc6HDPAAcC69j6JusGeLJs8aubDjJAtPzU=; b=0cIgbkM9fzhnJwQ+AI31/w8+9Ko6R6hnvHzx4fs2feLSWTAVO70fjMhGkjPW3SG0Sb ylLfY6Eeb+L2VSG9NhHX3ntFXyfPGPnf6XeuAfFFKK+MuNQuFWxsSDTCF2po4kX5u61b ifka4FjgYLp0Ln+17IDVQ3Wzvtp/DWOC5FAekmX83oa4LEZ6EX2DFULCVYcWeRX37oeo QHXI8HtRXbfzcHBXcqTYhes0nfUAODtlm6Hm0pFrEpIi49K0sQXV8aWBQkKG+wfC11wI f7VFE6LtsFo7HFRjkrZeeBOhdvNkl0XC2IRwGXCdMJ4JLglATgCft6OqHvkZoBNphDG5 n06Q== Received: by 10.180.83.106 with SMTP id p10mr4461379wiy.21.1343221447260; Wed, 25 Jul 2012 06:04:07 -0700 (PDT) Received: from [10.0.0.86] ([93.152.184.10]) by mx.google.com with ESMTPS id bc2sm3935257wib.0.2012.07.25.06.04.05 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 25 Jul 2012 06:04:05 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Nikolay Denev In-Reply-To: Date: Wed, 25 Jul 2012 16:04:03 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: m s X-Mailer: Apple Mail (2.1278) Cc: freebsd-net@freebsd.org Subject: Re: Enable/Disable flow control in FreeBSD X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 13:04:08 -0000 On Jul 25, 2012, at 11:47 AM, m s wrote: > Hi all. I want to disbale flow control on network interfaces.I must do = a > test and I can't because flow control in enable.Is it enable as = default?How > I can disable it? > Thanks > _______________________________________________ > 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" It depends on whether the driver supports it. The drivers that support it can control it with the ifconfig(8) media = options. You can try "ifconfig -m $your_interface" to see if there are any = mediaopts regarding flow control. From owner-freebsd-net@FreeBSD.ORG Wed Jul 25 17:25:27 2012 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 F1C4C106566B for ; Wed, 25 Jul 2012 17:25:27 +0000 (UTC) (envelope-from jeffrey.e.pieper@intel.com) Received: from mga03.intel.com (mga03.intel.com [143.182.124.21]) by mx1.freebsd.org (Postfix) with ESMTP id BC0D58FC18 for ; Wed, 25 Jul 2012 17:25:27 +0000 (UTC) Received: from azsmga002.ch.intel.com ([10.2.17.35]) by azsmga101.ch.intel.com with ESMTP; 25 Jul 2012 10:25:27 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="126817714" Received: from orsmsx603.amr.corp.intel.com ([10.22.226.49]) by AZSMGA002.ch.intel.com with ESMTP; 25 Jul 2012 10:25:27 -0700 Received: from orsmsx106.amr.corp.intel.com (10.22.225.133) by orsmsx603.amr.corp.intel.com (10.22.226.49) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 25 Jul 2012 10:25:26 -0700 Received: from orsmsx101.amr.corp.intel.com ([169.254.8.93]) by ORSMSX106.amr.corp.intel.com ([169.254.5.44]) with mapi id 14.01.0355.002; Wed, 25 Jul 2012 10:25:26 -0700 From: "Pieper, Jeffrey E" To: "freebsd-net@freebsd.org" Thread-Topic: Enable/Disable flow control in FreeBSD Thread-Index: AQHNakJLR8dAmaFfEkek4z8iugK99pc6bMGA///PujA= Date: Wed, 25 Jul 2012 17:25:25 +0000 Message-ID: <2A35EA60C3C77D438915767F458D65685052DEB4@ORSMSX101.amr.corp.intel.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.22.254.139] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: RE: Enable/Disable flow control in FreeBSD X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 17:25:28 -0000 -----Original Message----- From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd-net@freebsd.org] = On Behalf Of Nikolay Denev Sent: Wednesday, July 25, 2012 6:04 AM To: m s Cc: freebsd-net@freebsd.org Subject: Re: Enable/Disable flow control in FreeBSD On Jul 25, 2012, at 11:47 AM, m s wrote: > Hi all. I want to disbale flow control on network interfaces.I must do a > test and I can't because flow control in enable.Is it enable as default?H= ow > I can disable it? > Thanks > _______________________________________________ > 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" > >It depends on whether the driver supports it. >The drivers that support it can control it with the ifconfig(8) media opti= ons. >You can try "ifconfig -m $your_interface" to see if there are any mediaopt= s regarding flow control. Intel devices use sysctl to enable/disable flow control: #sysctl -a|grep fc dev.em.X.fc:3 dev.igb.X.fc:3 dev.ix.X.fc:3 Hope this helps. From owner-freebsd-net@FreeBSD.ORG Wed Jul 25 18:21:07 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC4301065675; Wed, 25 Jul 2012 18:21:07 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 8A9D98FC1E; Wed, 25 Jul 2012 18:21:07 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 16CBA7300A; Wed, 25 Jul 2012 20:41:04 +0200 (CEST) Date: Wed, 25 Jul 2012 20:41:04 +0200 From: Luigi Rizzo To: net@freebsd.org Message-ID: <20120725184104.GA35621@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: ipfw@freebsd.org Subject: PREVIEW - netmap-enabled ipfw 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, 25 Jul 2012 18:21:07 -0000 First and foremost: this is just a preview, only usable for testing now, but very very close to working. http://info.iet.unipi.it/~luigi/netmap/20120725-ipfw-user.tgz At the above URL you can find a userspace version of ipfw that reads packet from a netmap-compatible port (i.e. a netmap supported interface, or a port on a VALE bridge), and processes them through ipfw. It builds and run on both linux and FreeBSD, and uses the ipfw sources from today's HEAD. Right now the output is thrown away, but very shortly the code will also send it to an output port. The way it works is very simple (see also the picture below, drawn with http://www.asciiflow.com/ ) The formerly-kernel-side part of the firewall now runs in a userspace process (kipfw) and is controlled by a slightly modified ipfw that routes the sockopt commands over TCP to localhost:5555 (hardwired). kipfw stores rules persistently, and also reads from a netmap port. The configuration below shows how to use pkt-gen to test the performance of the system: you need to load the VALE-enabled netmap module, then in one terminal run "kipfw vale-test", in another terminal use the ipfw that you just built to add/delete/show stuff, and you can use netmap's pkt-gen to generate traffic. +------------+ | | +----------+ +----------------+ | | | | tcp/5555 | | | pkt-gen | | ipfw +--------->| kipfw | | | | | | | | | +----------+ +----------------+ +-----+------+ ^ | | | | | | v +-------+--------------------------+ | | | VALE bridge | | | +----------------------------------+ A quick test with a simple ruleset (4 rules, see below) shows a processing speed of 9-10Mpps on one core. I think there is still room for a little bit of improvement. Especially, we can now test the performance impact of changes to the firewall code without the need for complex hardware setups. > ipfw/ipfw show connected to 127.0.0.1:5555 00100 30628621 1408916566 count ip from any to any dst-ip 10.1.0.1 00100 0 0 count ip from any to any dst-ip 10.1.0.2 00100 0 0 count ip from any to any dst-ip 10.1.0.3 65535 30628621 1408916566 allow ip from any to any cheers luigi From owner-freebsd-net@FreeBSD.ORG Wed Jul 25 20:21:06 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9E15E106566B for ; Wed, 25 Jul 2012 20:21:06 +0000 (UTC) (envelope-from nitroboost@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 58E258FC08 for ; Wed, 25 Jul 2012 20:21:06 +0000 (UTC) Received: by yhfs35 with SMTP id s35so1397072yhf.13 for ; Wed, 25 Jul 2012 13:21:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ckM9bQtrl7ZeaBVmVzS7jpjHIPL5NNBSQ1RbnAtsL7o=; b=zohK55hTeuh5i3Cd44J8AUOCW0qFxdm5ZVoITohZNcDg6LbP7NEKUbQS1vljQFhm9C c4m5oYpRGXzQujafxcpSCazME6noMBcbEVDs2d/H6FDGw5Gnkn7oPbnWtsAHdX+O5eel 4ucP0SKS6KhOQFQA46a/c6KQn1sQDB11XM3B7NQ4u0dhzbTWOgsq2hi+suF1NRkB4CiK HmKdG4OzYsQ2mT1DeJtAtgnrTBR4RPDAwM9nmGaUFwCHyNoQNZKc6SUhCloCm6oHAsjF zHBkpQFAF9l2ECkjviNPW/iEivMNVLp8b1uxhEZyhkge2u5RrZR5pKSYH+ipl15LFL+w lqmA== MIME-Version: 1.0 Received: by 10.50.203.41 with SMTP id kn9mr48091igc.72.1343247665602; Wed, 25 Jul 2012 13:21:05 -0700 (PDT) Received: by 10.231.31.140 with HTTP; Wed, 25 Jul 2012 13:21:05 -0700 (PDT) In-Reply-To: <4FFFBA0D.7080505@norma.perm.ru> References: <4FFFBA0D.7080505@norma.perm.ru> Date: Wed, 25 Jul 2012 13:21:05 -0700 Message-ID: From: Jason Wolfe To: "Eugene M. Zheganin" Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org Subject: Re: Broadcom NetXtreme BCM5719 support X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 20:21:06 -0000 On Thu, Jul 12, 2012 at 11:02 PM, Eugene M. Zheganin wrote: > Hi. > > > On 13.07.2012 04:39, Jason Wolfe wrote: >> >> bge0: mem >> 0xf6bf0000-0xf6bfffff,0xf6be0000-0xf6beffff,0xf6bd0000-0xf6bdffff irq >> 32 at device 0.0 on pci3 >> bge0: CHIP ID 0x05719001; ASIC REV 0x5719; CHIP REV 0x57190; PCI-E >> miibus0: on bge0 >> bge0: Ethernet Address: xx:xx:xx:xx:xx:xx >> ... >> bge0: watchdog timeout -- resetting >> bge0: link state changed to UP >> bge0: link state changed to DOWN >> bge0: link state changed to UP >> bge0: link state changed to DOWN >> bge0: link state changed to UP >> bge0: link state changed to DOWN >> ... >> >> >> bge0@pci:0:3:0:0: class=0x020000 card=0x169d103c chip=0x165714e4 >> rev=0x01 hdr=0x00 >> vendor = 'Broadcom Corporation' >> device = 'NetXtreme BCM5719 Gigabit Ethernet PCIe' >> class = network >> subclass = ethernet >> >> Anything in the pipe on this one, or any access I can provide that >> might assist us? >> > I got a BMC5722 chip (and IBM x3250 mX systems), but same stuff with > timeout/resets. I can say 8.1/8.2 were more stable concerning bge(4). > You could try to switch off tso and vlanhwtso, at least it did the trick for > me (did it ? not sure though. I was having problems one a month on 8.1/8.2, > after upgrading to 8.3-STABLE I start having problems with it every day, > literally, after ifconfig bge0 -tso -vlanhwtso it's running for 5 day now.) > > Eugene. Yeah, I had no luck even with all options disabled. The NIC constantly bounces, and ifconfig never reports anything but "status: no carrier". No love on the driver side for this NetXtreme BCM5719 Gigabit Ethernet PCIe card? Jason From owner-freebsd-net@FreeBSD.ORG Thu Jul 26 01:56:59 2012 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 2E9291065672; Thu, 26 Jul 2012 01:56:59 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id 57C788FC0C; Thu, 26 Jul 2012 01:56:58 +0000 (UTC) Received: by wibhm11 with SMTP id hm11so4625402wib.13 for ; Wed, 25 Jul 2012 18:56:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fhzF8JyuwbqS8fVrWcEZ31l1TbaG1o7MwkqNM54vAYM=; b=bx/ck+YCoSzdZdM40y+pWEKQ+WCKp0njuPN5rcCf940wWcnAfuxQsYK4dbLGhQ5xWu qF5RF21mDgPf2AxbqXhe2fmtr59HD/NXTcZCpZtHmfwpKPS+j+4mZF+CoMg9kABZyTmd Y+Mggi1G+c/h13gYJI6GTB5GY1f8V40rbwW50v0SvleJp0rkaTJ2XGAACbfPU7s9R3Vx 2oZkKDhWynfTzCQrtfOpn0uroPUtUC7yIM3in0YsH1kDL50eZuqaIVIJsoOOFLO07NMX XqFvdUTMijdxazR5/7PHdoVjxCkRvKppUUFKlX6hx27JGDXj/Gdnt6pL1NMt5t5siAwe FxwA== MIME-Version: 1.0 Received: by 10.180.84.104 with SMTP id x8mr9201281wiy.20.1343267817120; Wed, 25 Jul 2012 18:56:57 -0700 (PDT) Received: by 10.216.227.70 with HTTP; Wed, 25 Jul 2012 18:56:57 -0700 (PDT) In-Reply-To: <500FD7B9.4070804@freebsd.org> References: <500FD7B9.4070804@freebsd.org> Date: Wed, 25 Jul 2012 21:56:57 -0400 Message-ID: From: Arnaud Lacombe To: Andre Oppermann Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Net , FreeBSD Hackers Subject: Re: Generic queue's KPI to manipulate mbuf's queue 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, 26 Jul 2012 01:56:59 -0000 Hi, On Wed, Jul 25, 2012 at 7:25 AM, Andre Oppermann wrote: > On 24.07.2012 20:18, Arnaud Lacombe wrote: >> >> Hi, >> >> AFAIK, there is no proper KPI for managing mbuf queue. All users have > Before we can talk about an mbuf queue you have to define what you > want to "queue". Is it packets or an mbuf chain which doesn't have > clear delimiters (as with tcp for example)? Depending on that the > requirements and solutions may be vastly different. > I was thinking about queues as in "general use-case of m_nextpkt", that would be dummynet queuing, QoS, various reassembly queues, socket buffer, etc... >> to re-implements the queue logic from scratch, which is less than >> optimal. From a preeminent FreeBSD developer at BSDCan 2009: "we do >> not need a new list implementation". There has been a few attempt of >> providing a queue API, namely , but that is >> nothing more than an ad-hoc solution to something which _has_to_be_ >> generic. For the sake of adding more mess in the tree, this >> implementation has been duplicated in ... > > Duplication is always a sign for the need of a generic approach/KPI. > > >> Now, I understand, or at least merely witness without power, the >> reluctance of kernel hackers to have 'struct mbuf` evolves, especially >> wrt. their desire to keep binary compatibility of KPI[0]. Now, none of >> the current ad-hoc API matched my needs, and I really did NOT want to >> re-implement a new list implementation for missing basic operation, >> such as deleting an element of the list, so I came with the attached >> patch. The main idea is to be able to use already existing code from >> for mbuf queuing management. It is not the best which >> can be done. I am not a huge fan of keeping `m_nextpkt' and >> introducing a `m_nextelm', I would have preferred to use TAILQs, and I >> do not like the dwelling in SLIST internal implementation details. >> However, this change is relatively lightweight, and change neither ABI >> or API. > > IMO your change is a rather elegant way of introducing the LIST macros > to the mbuf nextpkt field. I do like it and don't object to it providing > you sufficiently answer the question in the first paragraph. > actually, I made a mistake selecting SLISTs, it should really be an STAILQ. It has the same advantage wrt. ABI, and most usage made of `m_nextpkt' follows a tail queue logic. The only advantage of TAILQ would be reverse traversal, and time constant removal of inner elements. - Arnaud > -- > Andre > >> Any comment appreciated. >> >> - Arnaud >> >> [0]: taking care of having a stable kernel ABI and *not* a stable >> userland ABI is beyond my understanding, but this is not the subject >> of this mail. >> >> >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > From owner-freebsd-net@FreeBSD.ORG Thu Jul 26 05:34:54 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BBD2F106566B; Thu, 26 Jul 2012 05:34:54 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 8DD158FC08; Thu, 26 Jul 2012 05:34:54 +0000 (UTC) Received: from JRE-MBP-2.local (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id q6Q5Yic0048033 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 25 Jul 2012 22:34:46 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <5010D6EF.9040805@freebsd.org> Date: Wed, 25 Jul 2012 22:34:39 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Luigi Rizzo References: <20120725184104.GA35621@onelab2.iet.unipi.it> In-Reply-To: <20120725184104.GA35621@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipfw@freebsd.org, net@freebsd.org Subject: Re: PREVIEW - netmap-enabled ipfw 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, 26 Jul 2012 05:34:54 -0000 On 7/25/12 11:41 AM, Luigi Rizzo wrote: > First and foremost: this is just a preview, only usable for testing now, > but very very close to working. > > http://info.iet.unipi.it/~luigi/netmap/20120725-ipfw-user.tgz > > [...] > connected to 127.0.0.1:5555 > 00100 30628621 1408916566 count ip from any to any dst-ip 10.1.0.1 > 00100 0 0 count ip from any to any dst-ip 10.1.0.2 > 00100 0 0 count ip from any to any dst-ip 10.1.0.3 > 65535 30628621 1408916566 allow ip from any to any how do you handle rules that require to be able to see routes and socket owners? From owner-freebsd-net@FreeBSD.ORG Thu Jul 26 05:54:59 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 66805106566C; Thu, 26 Jul 2012 05:54:59 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 21F2F8FC08; Thu, 26 Jul 2012 05:54:59 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 8F1D47300A; Thu, 26 Jul 2012 08:14:56 +0200 (CEST) Date: Thu, 26 Jul 2012 08:14:56 +0200 From: Luigi Rizzo To: Julian Elischer Message-ID: <20120726061456.GB42206@onelab2.iet.unipi.it> References: <20120725184104.GA35621@onelab2.iet.unipi.it> <5010D6EF.9040805@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5010D6EF.9040805@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: ipfw@freebsd.org, net@freebsd.org Subject: Re: PREVIEW - netmap-enabled ipfw 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, 26 Jul 2012 05:54:59 -0000 On Wed, Jul 25, 2012 at 10:34:39PM -0700, Julian Elischer wrote: > On 7/25/12 11:41 AM, Luigi Rizzo wrote: > >First and foremost: this is just a preview, only usable for testing now, > >but very very close to working. > > > > http://info.iet.unipi.it/~luigi/netmap/20120725-ipfw-user.tgz > > > >[...] > > > connected to 127.0.0.1:5555 > > 00100 30628621 1408916566 count ip from any to any dst-ip 10.1.0.1 > > 00100 0 0 count ip from any to any dst-ip 10.1.0.2 > > 00100 0 0 count ip from any to any dst-ip 10.1.0.3 > > 65535 30628621 1408916566 allow ip from any to any > > > how do you handle rules that require to be able to see routes and > socket owners? I don't, at least not at this level. Let me elaborate. This project is meant to be used at very high packet rates, and in a router/switch environment. Think of it as a first-level defense against attacks, or a fast NAT device, wich deals with the bulk of the traffic and forwards the rest to the output interface or to the host stack. At the next hop (e.g. in the host stack), you can still have another firewall instance that does the more complex lookups such as socket owners, routes and whatnot. The next step would be to export forwarding information to userspace so you can lookup routes from there too. In principle it should not be that hard to listen for updates on the routing socket and rebuild a forwarding table to be looked up. One could devise a similar strategy for sockets, providing an interface for applications to query existing sockets (we have a sysctl now, i believe) and be notified of creations/destructions of sockets (similar to routing updates; i don't know if this is supported, though) and this will make socket info available to userspace too. cheers luigi From owner-freebsd-net@FreeBSD.ORG Thu Jul 26 08:35:30 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9099D106566C for ; Thu, 26 Jul 2012 08:35:30 +0000 (UTC) (envelope-from mah.s.369@gmail.com) Received: from mail-qa0-f54.google.com (mail-qa0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4B12F8FC08 for ; Thu, 26 Jul 2012 08:35:30 +0000 (UTC) Received: by qaat11 with SMTP id t11so1132812qaa.13 for ; Thu, 26 Jul 2012 01:35:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Xt+CUOPyjz4TpQ8hVbFGFkqeGM2TVa48TOeqglcOxCM=; b=iv0dpPtWfXHsB7+kpeokCjh2+kVa/iDr0KErskIMRgzIxv3wu+4SusJ4Su+XXQVLB9 rKUN6SsCdAyUisUSv8oK5YH6b8crAE/Lhc9Sifgy686RfX/kaAFaHGCXH1P+G11krafp 44Ri485t+zm8omUnq5GSL6UBuyrUBJ9V8F1zdBN/NVXEKWM0+upSdG5TtgDRrFhOx+1p XL+DXsdGaCYWTEPvs9HdsLDLnXcpriasNn4n57UyOn01V27p80KmMjoboDO586yF6Ort u2l4g4tmjudJuHtsPMj3XhvBt8J3Y4d8tNDN+5TiCViERUyMOf3frOLrTYjD2sqy8Ub/ YOwQ== MIME-Version: 1.0 Received: by 10.229.135.146 with SMTP id n18mr12696794qct.138.1343291729569; Thu, 26 Jul 2012 01:35:29 -0700 (PDT) Received: by 10.49.86.196 with HTTP; Thu, 26 Jul 2012 01:35:29 -0700 (PDT) Date: Thu, 26 Jul 2012 08:35:29 +0000 Message-ID: From: m s To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: tcpdump in freebsd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 08:35:30 -0000 hi all. I want to use tcpdump just for input or just for outout packet.isthis possible ? if no is there any other command that do this? thanks From owner-freebsd-net@FreeBSD.ORG Thu Jul 26 08:40:45 2012 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 0BAAE106570E for ; Thu, 26 Jul 2012 08:40:45 +0000 (UTC) (envelope-from pprocacci@datapipe.com) Received: from EXFESMQ04.datapipe-corp.net (exfesmq04.datapipe.com [64.27.120.68]) by mx1.freebsd.org (Postfix) with ESMTP id B29CF8FC14 for ; Thu, 26 Jul 2012 08:40:44 +0000 (UTC) Received: from nat.myhome (192.168.128.103) by EXFESMQ04.datapipe-corp.net (192.168.128.29) with Microsoft SMTP Server (TLS) id 14.2.298.4; Thu, 26 Jul 2012 04:39:28 -0400 Date: Thu, 26 Jul 2012 03:39:49 -0500 From: "Paul A. Procacci" To: m s Message-ID: <20120726083949.GC2173@nat.myhome> References: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Originating-IP: [192.168.128.103] Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: tcpdump in freebsd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 08:40:45 -0000 tcpdump -ni src host tcpdump -ni not src host ~Paul On Thu, Jul 26, 2012 at 08:35:29AM +0000, m s wrote: > hi all. I want to use tcpdump just for input or just for outout > packet.isthis possible ? if no is there any other command that do > this? > thanks > _______________________________________________ > 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" ________________________________ This message may contain confidential or privileged information. If you are= not the intended recipient, please advise us immediately and delete this m= essage. See http://www.datapipe.com/legal/email_disclaimer/ for further inf= ormation on confidentiality and the risks of non-secure electronic communic= ation. If you cannot access these links, please notify us by reply message = and we will send the contents to you. From owner-freebsd-net@FreeBSD.ORG Thu Jul 26 09:25:57 2012 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 ABFC8106566C for ; Thu, 26 Jul 2012 09:25:57 +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 235828FC0A for ; Thu, 26 Jul 2012 09:25:56 +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 q6Q9PnnY025326 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Jul 2012 11:25:49 +0200 (MEST) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.14.1/8.12.10/Submit) id q6Q9Pnen009817; Thu, 26 Jul 2012 11:25:49 +0200 (MEST) Date: Thu, 26 Jul 2012 11:25:49 +0200 From: Daniel Hartmeier To: m s Message-ID: <20120726092549.GA3153@insomnia.benzedrine.cx> References: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="IJpNTDwzlM2Ie8A6" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.12-2006-07-14 Cc: freebsd-net@freebsd.org Subject: Re: tcpdump in freebsd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 09:25:57 -0000 --IJpNTDwzlM2Ie8A6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Jul 26, 2012 at 08:35:29AM +0000, m s wrote: > hi all. I want to use tcpdump just for input or just for outout > packet.isthis possible ? if no is there any other command that do > this? If filtering by source MAC (or IP) is not enough, you can patch tcpdump to hack in '-a in|out' using pcap_setdirection(). HTH, Daniel --IJpNTDwzlM2Ie8A6 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="tcpdump.diff" Index: contrib/tcpdump/tcpdump.1 =================================================================== RCS file: /home/ncvs/src/contrib/tcpdump/Attic/tcpdump.1,v retrieving revision 1.19.2.1.8.1 diff -u -r1.19.2.1.8.1 tcpdump.1 --- contrib/tcpdump/tcpdump.1 3 Mar 2012 06:15:13 -0000 1.19.2.1.8.1 +++ contrib/tcpdump/tcpdump.1 26 Jul 2012 09:16:17 -0000 @@ -33,6 +33,12 @@ [ .B \-AdDefIKlLnNOpqRStuUvxX ] [ +.B \-a +.I direction +] +.br +.ti +8 +[ .B \-B .I buffer_size ] [ @@ -194,6 +200,9 @@ special privileges. .SH OPTIONS .TP +.B \-a +Print only packets matching \fIdirection\fP, \fBin\fP or \fBout\fP. +.TP .B \-A Print each packet (minus its link level header) in ASCII. Handy for capturing web pages. Index: contrib/tcpdump/tcpdump.c =================================================================== RCS file: /home/ncvs/src/contrib/tcpdump/tcpdump.c,v retrieving revision 1.14.2.1.8.1 diff -u -r1.14.2.1.8.1 tcpdump.c --- contrib/tcpdump/tcpdump.c 3 Mar 2012 06:15:13 -0000 1.14.2.1.8.1 +++ contrib/tcpdump/tcpdump.c 26 Jul 2012 09:03:27 -0000 @@ -295,6 +298,7 @@ } static pcap_t *pd; +static pcap_direction_t aflag = PCAP_D_INOUT; extern int optind; extern int opterr; @@ -537,11 +541,16 @@ opterr = 0; while ( - (op = getopt(argc, argv, "aA" B_FLAG "c:C:d" D_FLAG "eE:fF:G:i:" I_FLAG "KlLm:M:nNOpqr:Rs:StT:u" U_FLAG "vw:W:xXy:Yz:Z:")) != -1) + (op = getopt(argc, argv, "a:A" B_FLAG "c:C:d" D_FLAG "eE:fF:G:i:" I_FLAG "KlLm:M:nNOpqr:Rs:StT:u" U_FLAG "vw:W:xXy:Yz:Z:")) != -1) switch (op) { case 'a': - /* compatibility for old -a */ + if (!strcmp(optarg, "in")) + aflag = PCAP_D_IN; + else if (!strcmp(optarg, "out")) + aflag = PCAP_D_OUT; + else + error("invalid direction %s", optarg); break; case 'A': @@ -1023,6 +1032,12 @@ else if (*ebuf) warning("%s", ebuf); #endif /* HAVE_PCAP_CREATE */ + if (aflag != PCAP_D_INOUT) { + status = pcap_setdirection(pd, aflag); + if (status != 0) + error("%s: pcap_setdirection failed: %s", + device, pcap_statustostr(status)); + } /* * Let user own process after socket has been opened. */ --IJpNTDwzlM2Ie8A6-- From owner-freebsd-net@FreeBSD.ORG Thu Jul 26 09:40:14 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B4572106566B for ; Thu, 26 Jul 2012 09:40:14 +0000 (UTC) (envelope-from mah.s.369@gmail.com) Received: from mail-qa0-f47.google.com (mail-qa0-f47.google.com [209.85.216.47]) by mx1.freebsd.org (Postfix) with ESMTP id 696FD8FC0C for ; Thu, 26 Jul 2012 09:40:14 +0000 (UTC) Received: by qabg1 with SMTP id g1so3364932qab.13 for ; Thu, 26 Jul 2012 02:40:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=T/5NlLSbFAtSHs+GHqm7Uqzdl5A9PtJv56nmRrrWees=; b=PlW9xpzB9k7EhfOgFuo9YTLNbjC44fcFmH5mfGGRqinaAmZNjX9JgOl9kTJjxG43AL nIhDBpWdz3zynHnh/OvoIoebm7tRHlKoIfjxz+mAruaCKxrhAL3u1R28hgVi5wJpXBea v5UiJjs498MlUzZoC8zZa/ZgvQZBpox9GQhLPh++XYQ9QE4nGmPW+92ru0VfArGA731l tZfgoEu0xHIYw7rb0qDEq5ULznO6xxHpxf9xMPcVrCPynBu4NiFhMcWG791tpWwXm7f5 ZxRog9oH7DufuuiU3DFna7k1iPWvs8XEqNrkER+z087rIrzpWO5vF8FS69ein/ZC39UY VWiQ== MIME-Version: 1.0 Received: by 10.224.221.143 with SMTP id ic15mr1965258qab.51.1343295607905; Thu, 26 Jul 2012 02:40:07 -0700 (PDT) Received: by 10.49.86.196 with HTTP; Thu, 26 Jul 2012 02:40:07 -0700 (PDT) In-Reply-To: <20120726092549.GA3153@insomnia.benzedrine.cx> References: <20120726092549.GA3153@insomnia.benzedrine.cx> Date: Thu, 26 Jul 2012 09:40:07 +0000 Message-ID: From: m s To: Daniel Hartmeier Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: tcpdump in freebsd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 09:40:14 -0000 thank you for your help. I will test it On Thu, Jul 26, 2012 at 9:25 AM, Daniel Hartmeier wrote: > On Thu, Jul 26, 2012 at 08:35:29AM +0000, m s wrote: > > > hi all. I want to use tcpdump just for input or just for outout > > packet.isthis possible ? if no is there any other command that do > > this? > > If filtering by source MAC (or IP) is not enough, you can patch tcpdump > to hack in '-a in|out' using pcap_setdirection(). > > HTH, > Daniel > From owner-freebsd-net@FreeBSD.ORG Thu Jul 26 13:24:16 2012 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 02996106582E for ; Thu, 26 Jul 2012 13:24:15 +0000 (UTC) (envelope-from mah.s.369@gmail.com) Received: from mail-qa0-f54.google.com (mail-qa0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 70C8E8FC0A for ; Thu, 26 Jul 2012 13:24:15 +0000 (UTC) Received: by qaat11 with SMTP id t11so1258111qaa.13 for ; Thu, 26 Jul 2012 06:24:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8YyvSSmi93gQcobYjsEyH5JzZJzx/tmM/eUVl2yun3w=; b=Yvx+qoZddrRruB8w7Htp5qlFE7jjuzCb/xRfCTmhQJwy3qZ6kTcE+/o3NndG9DvV93 95OAxSivO9eMdiCJJIpGWxUNvYU2m3MlVtswUzT+2R7micZkDCllZK0+Y8/NuB+2Er+h FlkYm+1YOocfU8NEnyc9aYLlgYc4wGdaXLiW1WSTbwOb87up1ngrTfJXYH+ayADrSzDA 1aQzkcZBvZDGqgpHjzXfLKHAbNUzpzbH+gvyUTqzrahsU2TCwF1R2DQcwJ36LAtgTmLh tuPK7JmjJe6vZnBAtSdqrVb0buvUDzR/75h9yW2bY7vV9RFcXXxFFOlsJRAbwGqX1b0L z4jA== MIME-Version: 1.0 Received: by 10.224.203.132 with SMTP id fi4mr2841709qab.76.1343309053912; Thu, 26 Jul 2012 06:24:13 -0700 (PDT) Received: by 10.49.86.196 with HTTP; Thu, 26 Jul 2012 06:24:13 -0700 (PDT) In-Reply-To: <20120726092549.GA3153@insomnia.benzedrine.cx> References: <20120726092549.GA3153@insomnia.benzedrine.cx> Date: Thu, 26 Jul 2012 06:24:13 -0700 Message-ID: From: m s To: Daniel Hartmeier Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: tcpdump in freebsd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 13:24:16 -0000 It works correct.Thanks for your help. On Thu, Jul 26, 2012 at 2:25 AM, Daniel Hartmeier wrote: > On Thu, Jul 26, 2012 at 08:35:29AM +0000, m s wrote: > > > hi all. I want to use tcpdump just for input or just for outout > > packet.isthis possible ? if no is there any other command that do > > this? > > If filtering by source MAC (or IP) is not enough, you can patch tcpdump > to hack in '-a in|out' using pcap_setdirection(). > > HTH, > Daniel > From owner-freebsd-net@FreeBSD.ORG Thu Jul 26 17:34:42 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id C6AC4106564A for ; Thu, 26 Jul 2012 17:34:42 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from [127.0.0.1] (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 6928014FA2C for ; Thu, 26 Jul 2012 17:34:42 +0000 (UTC) Message-ID: <50117FB2.1060306@FreeBSD.org> Date: Thu, 26 Jul 2012 10:34:42 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: freebsd-net@FreeBSD.org References: <50117DB0.7010909@mh-sec.de> In-Reply-To: <50117DB0.7010909@mh-sec.de> X-Enigmail-Version: 1.4.2 OpenPGP: id=1A1ABC84 X-Forwarded-Message-Id: <50117DB0.7010909@mh-sec.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: Subject: Fwd: Re: [ipv6hackers] funny FreeBSD bug 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, 26 Jul 2012 17:34:42 -0000 FYI, this conversation is happening in the list below. I have no opinion regarding whether it is a bug or not, but I thought folks here might be interested. Doug -------- Original Message -------- Subject: Re: [ipv6hackers] funny FreeBSD bug Date: Thu, 26 Jul 2012 19:26:08 +0200 From: Marc Heuse Reply-To: IPv6 Hackers Mailing List To: IPv6 Hackers Mailing List , Simon Perreault Hi Simon, Am 26.07.2012 17:47, schrieb Simon Perreault: > Le 2012-07-26 08:35, Marc Heuse a écrit : >> I found a funny bug in freebsd (9.0 with all updates): >> if you send an ICMP toobig message to it with a too low MTU size, >> FreeBSD will prepend any packet data with an one-shot fragment (or >> atomic fragment as Fernando calls it). > > Why do you think it's a bug? first it servs no use to add the fragmentation header if the packet is not fragmented. second I have not seen this behaviour in other OS, however I havent looked for it though. > Seems like normal IPv6 behaviour to me. It's in the RFC... I cant remember having seen this in any rfc - do you have a pointer? Greets, Marc -- Marc Heuse www.mh-sec.de PGP: FEDD 5B50 C087 F8DF 5CB9 876F 7FDD E533 BF4F 891A _______________________________________________ Ipv6hackers mailing list Ipv6hackers@lists.si6networks.com http://lists.si6networks.com/listinfo/ipv6hackers From owner-freebsd-net@FreeBSD.ORG Fri Jul 27 09:26:00 2012 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 9E34B1065686 for ; Fri, 27 Jul 2012 09:26:00 +0000 (UTC) (envelope-from andrnils@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 654C68FC1D for ; Fri, 27 Jul 2012 09:26:00 +0000 (UTC) Received: by obbun3 with SMTP id un3so5181396obb.13 for ; Fri, 27 Jul 2012 02:25:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=ofsLP5vN0jMKEUYSGj6gs7sYxf/yMRFd1V/yai0O4ug=; b=qQUhRvL3BhzdbaBPvwj/qRXU528Z+p//1zFBrQ5J49v9R5j9Q9nHNVzj11dF4aeJFc HgywoWQDEsfCuwwD2Pydom2aWk/oPtSEF6FLcOwy4Ln4bgKsNi0Ckb7HGlAtC7EV5b2a qhXKR7TzLoJNs5yVbgr8IBMaErOTNHgOJ9f74Ke6kDi+g/yoeDVx2IH5TJEURVNZMlSE 1kLTy5pmYF3amqqR4AJztU5r/310l6wUJWpovLYmnN5RO69iQM0lfdD29GJE/LBjj1hc 6sref/Tn0/3yH5DY/Wjwp3iTOB9CY+EWxS8hqht6Z8YalSB7xDcOPsiJ5t/paL2UC59I YaKA== MIME-Version: 1.0 Received: by 10.60.30.35 with SMTP id p3mr2685591oeh.16.1343381159742; Fri, 27 Jul 2012 02:25:59 -0700 (PDT) Received: by 10.60.32.81 with HTTP; Fri, 27 Jul 2012 02:25:59 -0700 (PDT) Date: Fri, 27 Jul 2012 11:25:59 +0200 Message-ID: From: Andreas Nilsson To: FreeBSD Net Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: iwn adhoc 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: Fri, 27 Jul 2012 09:26:00 -0000 Hello list, I'm trying use my nokia n9 as a wifi hotspot for my laptop, but cannot associate. The n9 is a bit peculiar, as it uses adhoc-mode for hotspot. I have network={ ssid="andrnils n9a" key_mgmt=NONE wep_tx_keyidx=0 wep_key0=[redacted] priority=50 mode=1 } in wpa_supplicant.conf . wpa_cli reveals <2>CTRL-EVENT-SCAN-RESULTS <2>Trying to associate with SSID 'andrnils n9a' <2>Association request to the driver failed and when I try to setup the connection manually with ifconfig I get ifconfig: SIOCIFCREATE2: Operation not supported and from reading older postings it seems that iwn has a problem with ad-hoc mode. I'm on 9-stable (r238754), hardware is lenovo thinkpad t510 iwn0@pci0:3:0:0: class=0x028000 card=0x11118086 chip=0x42388086 rev=0x35 hdr=0x00 vendor = 'Intel Corporation' device = 'Centrino Ultimate-N 6300' class = network Best regards Andreas Nilsson From owner-freebsd-net@FreeBSD.ORG Fri Jul 27 15:11:45 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 43E31106566B for ; Fri, 27 Jul 2012 15:11:45 +0000 (UTC) (envelope-from aboyer@averesystems.com) Received: from mail.averesystems.com (mail.averesystems.com [208.70.68.85]) by mx1.freebsd.org (Postfix) with ESMTP id 0D1568FC0C for ; Fri, 27 Jul 2012 15:11:45 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.averesystems.com (Postfix) with ESMTP id 912E34808CC; Fri, 27 Jul 2012 11:11:47 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.averesystems.com Received: from mail.averesystems.com ([127.0.0.1]) by localhost (mail.averesystems.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M+Zd+0zXUVDA; Fri, 27 Jul 2012 11:11:44 -0400 (EDT) Received: from riven.arriad.com (206.193.225.214.nauticom.net [206.193.225.214]) by mail.averesystems.com (Postfix) with ESMTPSA id B2D4C4808C5; Fri, 27 Jul 2012 11:11:44 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Andrew Boyer In-Reply-To: <5E4F49720D0BAD499EE1F01232234BA877435B2F66@AVEXMB1.qlogic.org> Date: Fri, 27 Jul 2012 11:11:41 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9BC66C40-6F4B-48A0-AEC0-DCAD0C6863EF@averesystems.com> References: <5E4F49720D0BAD499EE1F01232234BA877435B2E28@AVEXMB1.qlogic.org> <4C5FC147-2F49-4AE0-ADF3-C5381DE6580F@averesystems.com> <5E4F49720D0BAD499EE1F01232234BA877435B2F2E@AVEXMB1.qlogic.org> <5E4F49720D0BAD499EE1F01232234BA877435B2F66@AVEXMB1.qlogic.org> To: Adarsh Joshi X-Mailer: Apple Mail (2.1278) Cc: "freebsd-net@freebsd.org" Subject: Re: lacp lagg port flags do not show correctly resulting in poor traffic distribution/performance 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, 27 Jul 2012 15:11:45 -0000 Adarsh, Sorry for the delay. I'm not an LACP protocol expert, but looking at your logs I don't see = ql1 on either node receiving a lacpdu response. Are you certain that = link is working? -Andrew On Jul 10, 2012, at 1:53 PM, Adarsh Joshi wrote: > Andrew, >=20 > Here are the logs with LACP_DEBUG defined in ieee802.3ad_lacp.c, >=20 > after typing >=20 > Ifconfig lagg0 create > ifconfig lagg0 laggproto lacp laggport ql0 laggport ql1 192.168.100.1 = netmask 255.255.255.0 >=20 > I compiled it as a standalone driver by the way. >=20 > System 1: >=20 > # ifconfig -v lagg0 > lagg0: flags=3D8843 metric 0 = mtu 1500 > = options=3D13b > ether 00:0e:1e:08:05:20 > inet 192.168.100.1 netmask 0xffffff00 broadcast 192.168.100.255 > nd6 options=3D29 > media: Ethernet autoselect > status: active > groups: lagg > laggproto lacp > lag id: [(8000,00-0E-1E-08-05-20,01D3,0000,0000), > (8000,00-0E-1E-04-2C-F0,0213,0000,0000)] > laggport: ql1 flags=3D18 state=3D7D > [(8000,00-0E-1E-08-05-20,01D3,8000,000D), > (FFFF,00-00-00-00-00-00,0000,FFFF,0000)] > laggport: ql0 flags=3D1c = state=3D3D > [(8000,00-0E-1E-08-05-20,01D3,8000,000C), > (8000,00-0E-1E-04-2C-F0,0213,8000,000E)] >=20 >=20 > System 2: >=20 > # ifconfig -v lagg0 > lagg0: flags=3D8843 metric 0 = mtu 1500 > = options=3D13b > ether 00:0e:1e:04:2c:f0 > inet 192.168.100.2 netmask 0xffffff00 broadcast 192.168.100.255 > nd6 options=3D29 > media: Ethernet autoselect > status: active > groups: lagg > laggproto lacp > lag id: [(8000,00-0E-1E-04-2C-F0,0213,0000,0000), > (FFFF,00-00-00-00-00-00,0000,0000,0000)] > laggport: ql1 flags=3D1c = state=3D7D > [(8000,00-0E-1E-04-2C-F0,0213,8000,000F), > (FFFF,00-00-00-00-00-00,0000,FFFF,0000)] > laggport: ql0 flags=3D18 state=3D3D > [(8000,00-0E-1E-04-2C-F0,0213,8000,000E), > (8000,00-0E-1E-08-05-20,01D3,8000,000C)] >=20 >=20 > System 1 logs : >=20 > Jul 10 10:38:49 bsd-14 kernel: lacp_attach[738] : lacp attached > Jul 10 10:38:49 bsd-14 kernel: lacp_attach[740] : lacp_defined > Jul 10 10:38:49 bsd-14 kernel: lagg0: link state changed to UP > Jul 10 10:38:49 bsd-14 kernel: ql0: media changed 0x0 -> 0x100033, = ether =3D 1, fdx =3D 1, link =3D 1 > Jul 10 10:38:49 bsd-14 kernel: ql0: -> UNSELECTED > Jul 10 10:38:49 bsd-14 kernel: ql1: media changed 0x0 -> 0x100033, = ether =3D 1, fdx =3D 1, link =3D 1 > Jul 10 10:38:49 bsd-14 kernel: ql1: -> UNSELECTED > Jul 10 10:38:49 bsd-14 kernel: lacp_select_tx_port: no active = aggregator > Jul 10 10:38:50 bsd-14 kernel: ql1: port = lagid=3D[(8000,00-0E-1E-08-05-20,01D3,8000,000D),(0000,00-00-00-00-00-00,0= 000,0000,0000)] > Jul 10 10:38:50 bsd-14 kernel: ql1: aggregator created > Jul 10 10:38:50 bsd-14 kernel: ql1: aggregator = lagid=3D[(8000,00-0E-1E-08-05-20,01D3,0000,0000),(0000,00-00-00-00-00-00,0= 000,0000,0000)] > Jul 10 10:38:50 bsd-14 kernel: ql1: mux_state 0 -> 1 > Jul 10 10:38:50 bsd-14 kernel: ql0: port = lagid=3D[(8000,00-0E-1E-08-05-20,01D3,8000,000C),(0000,00-00-00-00-00-00,0= 000,0000,0000)] > Jul 10 10:38:50 bsd-14 kernel: ql0: aggregator created > Jul 10 10:38:50 bsd-14 kernel: ql0: aggregator = lagid=3D[(8000,00-0E-1E-08-05-20,01D3,0000,0000),(0000,00-00-00-00-00-00,0= 000,0000,0000)] > Jul 10 10:38:50 bsd-14 kernel: ql0: mux_state 0 -> 1 > Jul 10 10:38:51 bsd-14 kernel: ql1: lacpdu transmit > Jul 10 10:38:51 bsd-14 kernel: = actor=3D(8000,00-0E-1E-08-05-20,01D3,8000,000D) > Jul 10 10:38:51 bsd-14 kernel: = actor.state=3D85 > Jul 10 10:38:51 bsd-14 kernel: = partner=3D(0000,00-00-00-00-00-00,0000,0000,0000) > Jul 10 10:38:51 bsd-14 kernel: partner.state=3D2 > Jul 10 10:38:51 bsd-14 kernel: maxdelay=3D0 > Jul 10 10:38:51 bsd-14 kernel: ql0: lacpdu transmit > Jul 10 10:38:51 bsd-14 kernel: = actor=3D(8000,00-0E-1E-08-05-20,01D3,8000,000C) > Jul 10 10:38:51 bsd-14 kernel: = actor.state=3D85 > Jul 10 10:38:51 bsd-14 kernel: = partner=3D(0000,00-00-00-00-00-00,0000,0000,0000) > Jul 10 10:38:51 bsd-14 kernel: partner.state=3D2 > Jul 10 10:38:51 bsd-14 kernel: maxdelay=3D0 > Jul 10 10:38:51 bsd-14 kernel: ql0: lacpdu receive > Jul 10 10:38:51 bsd-14 kernel: = actor=3D(8000,00-0E-1E-04-2C-F0,0213,8000,000E) > Jul 10 10:38:51 bsd-14 kernel: actor.state=3D5 > Jul 10 10:38:51 bsd-14 kernel: = partner=3D(8000,00-0E-1E-08-05-20,01D3,8000,000C) > Jul 10 10:38:51 bsd-14 kernel: = partner.state=3D85 > Jul 10 10:38:51 bsd-14 kernel: maxdelay=3D0 > Jul 10 10:38:51 bsd-14 kernel: ql0: old pstate 2 > Jul 10 10:38:51 bsd-14 kernel: ql0: new pstate 5 > Jul 10 10:38:51 bsd-14 kernel: ql0: partner timeout changed > Jul 10 10:38:51 bsd-14 kernel: ql0: lacpdu receive > Jul 10 10:38:51 bsd-14 kernel: = actor=3D(8000,00-0E-1E-04-2C-F0,0213,8000,000E) > Jul 10 10:38:51 bsd-14 kernel: actor.state=3D5 > Jul 10 10:38:51 bsd-14 kernel: = partner=3D(8000,00-0E-1E-08-05-20,01D3,8000,000C) > Jul 10 10:38:51 bsd-14 kernel: = partner.state=3D85 > Jul 10 10:38:51 bsd-14 kernel: maxdelay=3D0 > Jul 10 10:38:52 bsd-14 kernel: ql1: lacp_sm_rx_timer: EXPIRED -> = DEFAULTED > Jul 10 10:38:52 bsd-14 kernel: ql1: partner timeout changed > Jul 10 10:38:52 bsd-14 kernel: ql1: lacp_sm_mux_timer: aggregator = [(8000,00-0E-1E-08-05-20,01D3,0000,0000),(0000,00-00-00-00-00-00,0000,0000= ,0000)], pending 1 -> 0 > Jul 10 10:38:52 bsd-14 kernel: ql1: collecting disabled > Jul 10 10:38:52 bsd-14 kernel: lacp_aggregator_delref: = lagid=3D[(8000,00-0E-1E-08-05-20,01D3,0000,0000),(0000,00-00-00-00-00-00,0= 000,0000,0000)], refcnt 1 -> 0 > Jul 10 10:38:52 bsd-14 kernel: ql1: mux_state 1 -> 0 > Jul 10 10:38:52 bsd-14 kernel: ql1: lacpdu transmit > Jul 10 10:38:52 bsd-14 kernel: = actor=3D(8000,00-0E-1E-08-05-20,01D3,8000,000D) > Jul 10 10:38:52 bsd-14 kernel: = actor.state=3D45 > Jul 10 10:38:52 bsd-14 kernel: = partner=3D(FFFF,00-00-00-00-00-00,0000,FFFF,0000) > Jul 10 10:38:52 bsd-14 kernel: = partner.state=3D3c > Jul 10 10:38:52 bsd-14 kernel: maxdelay=3D0 > Jul 10 10:38:52 bsd-14 kernel: ql0: lacp_sm_mux_timer: aggregator = [(8000,00-0E-1E-08-05-20,01D3,0000,0000),(0000,00-00-00-00-00-00,0000,0000= ,0000)], pending 1 -> 0 > Jul 10 10:38:52 bsd-14 kernel: ql0: collecting disabled > Jul 10 10:38:52 bsd-14 kernel: lacp_aggregator_delref: = lagid=3D[(8000,00-0E-1E-08-05-20,01D3,0000,0000),(0000,00-00-00-00-00-00,0= 000,0000,0000)], refcnt 1 -> 0 > Jul 10 10:38:52 bsd-14 kernel: ql0: mux_state 1 -> 0 > Jul 10 10:38:52 bsd-14 kernel: ql0: lacpdu transmit > Jul 10 10:38:52 bsd-14 kernel: = actor=3D(8000,00-0E-1E-08-05-20,01D3,8000,000C) > Jul 10 10:38:52 bsd-14 kernel: actor.state=3D5 > Jul 10 10:38:52 bsd-14 kernel: = partner=3D(8000,00-0E-1E-04-2C-F0,0213,8000,000E) > Jul 10 10:38:52 bsd-14 kernel: partner.state=3D5 > Jul 10 10:38:52 bsd-14 kernel: maxdelay=3D0 > Jul 10 10:38:53 bsd-14 kernel: ql1: port = lagid=3D[(8000,00-0E-1E-08-05-20,01D3,8000,000D),(FFFF,00-00-00-00-00-00,0= 000,FFFF,0000)] > Jul 10 10:38:53 bsd-14 kernel: ql1: aggregator created > Jul 10 10:38:53 bsd-14 kernel: ql1: aggregator = lagid=3D[(8000,00-0E-1E-08-05-20,01D3,0000,0000),(FFFF,00-00-00-00-00-00,0= 000,0000,0000)] > Jul 10 10:38:53 bsd-14 kernel: ql1: mux_state 0 -> 1 > Jul 10 10:38:53 bsd-14 kernel: ql0: port = lagid=3D[(8000,00-0E-1E-08-05-20,01D3,8000,000C),(8000,00-0E-1E-04-2C-F0,0= 213,8000,000E)] > Jul 10 10:38:53 bsd-14 kernel: ql0: aggregator created > Jul 10 10:38:53 bsd-14 kernel: ql0: aggregator = lagid=3D[(8000,00-0E-1E-08-05-20,01D3,0000,0000),(8000,00-0E-1E-04-2C-F0,0= 213,0000,0000)] > Jul 10 10:38:53 bsd-14 kernel: ql0: mux_state 0 -> 1 > Jul 10 10:38:54 bsd-14 kernel: ql0: lacpdu receive > Jul 10 10:38:54 bsd-14 kernel: = actor=3D(8000,00-0E-1E-04-2C-F0,0213,8000,000E) > Jul 10 10:38:54 bsd-14 kernel: = actor.state=3Dd > Jul 10 10:38:54 bsd-14 kernel: = partner=3D(8000,00-0E-1E-08-05-20,01D3,8000,000C) > Jul 10 10:38:54 bsd-14 kernel: partner.state=3D5 > Jul 10 10:38:54 bsd-14 kernel: maxdelay=3D0 > Jul 10 10:38:54 bsd-14 kernel: ql0: old pstate 5 > Jul 10 10:38:54 bsd-14 kernel: ql0: new pstate = d > Jul 10 10:38:55 bsd-14 kernel: ql1: lacp_sm_mux_timer: aggregator = [(8000,00-0E-1E-08-05-20,01D3,0000,0000),(FFFF,00-00-00-00-00-00,0000,0000= ,0000)], pending 1 -> 0 > Jul 10 10:38:55 bsd-14 kernel: ql1: collecting disabled > Jul 10 10:38:55 bsd-14 kernel: ql1: mux_state 1 -> 2 > Jul 10 10:38:55 bsd-14 kernel: ql1: collecting enabled > Jul 10 10:38:55 bsd-14 kernel: ql1: mux_state 2 -> 3 > Jul 10 10:38:55 bsd-14 kernel: ql1: enable distributing on aggregator = [(8000,00-0E-1E-08-05-20,01D3,0000,0000),(FFFF,00-00-00-00-00-00,0000,0000= ,0000)], nports 0 -> 1 > Jul 10 10:38:55 bsd-14 kernel: lacp_select_active_aggregator: > Jul 10 10:38:55 bsd-14 kernel: = [(8000,00-0E-1E-08-05-20,01D3,0000,0000),(FFFF,00-00-00-00-00-00,0000,0000= ,0000)], speed=3D10000000000, nports=3D1 > Jul 10 10:38:55 bsd-14 kernel: active aggregator changed > Jul 10 10:38:55 bsd-14 kernel: old (none) > Jul 10 10:38:55 bsd-14 kernel: new = [(8000,00-0E-1E-08-05-20,01D3,0000,0000),(FFFF,00-00-00-00-00-00,0000,0000= ,0000)] > Jul 10 10:38:55 bsd-14 kernel: Set table 1 with 1 ports > Jul 10 10:38:55 bsd-14 kernel: lacp_suppress_distributing > Jul 10 10:38:55 bsd-14 kernel: ql1: marker transmit, port=3D13, = sys=3D00:0e:1e:08:05:20, id=3D1 > Jul 10 10:38:55 bsd-14 kernel: ql0: marker transmit, port=3D12, = sys=3D00:0e:1e:08:05:20, id=3D1 > Jul 10 10:38:55 bsd-14 kernel: ql1: mux_state 3 -> 4 > Jul 10 10:38:55 bsd-14 kernel: ql1: lacpdu transmit > Jul 10 10:38:55 bsd-14 kernel: ql0: marker response, port=3D12, = sys=3D00:0e:1e:08:05:20, id=3D1 > Jul 10 10:38:55 bsd-14 kernel: = actor=3D(8000,00-0E-1E-08-05-20,01D3,8000,000D) > Jul 10 10:38:55 bsd-14 kernel: = actor.state=3D7d > Jul 10 10:38:55 bsd-14 kernel: = partner=3D(FFFF,00-00-00-00-00-00,0000,FFFF,0000) > Jul 10 10:38:55 bsd-14 kernel: = partner.state=3D3c > Jul 10 10:38:55 bsd-14 kernel: maxdelay=3D0 > Jul 10 10:38:55 bsd-14 kernel: ql0: lacp_sm_mux_timer: aggregator = [(8000,00-0E-1E-08-05-20,01D3,0000,0000),(8000,00-0E-1E-04-2C-F0,0213,0000= ,0000)], pending 1 -> 0 > Jul 10 10:38:55 bsd-14 kernel: ql0: collecting disabled > Jul 10 10:38:55 bsd-14 kernel: ql0: mux_state 1 -> 2 > Jul 10 10:38:55 bsd-14 kernel: ql0: collecting enabled > Jul 10 10:38:55 bsd-14 kernel: ql0: mux_state 2 -> 3 > Jul 10 10:38:55 bsd-14 kernel: ql0: lacpdu transmit > Jul 10 10:38:55 bsd-14 kernel: = actor=3D(8000,00-0E-1E-08-05-20,01D3,8000,000C) > Jul 10 10:38:55 bsd-14 kernel: = actor.state=3D1d > Jul 10 10:38:55 bsd-14 kernel: = partner=3D(8000,00-0E-1E-04-2C-F0,0213,8000,000E) > Jul 10 10:38:55 bsd-14 kernel: = partner.state=3Dd > Jul 10 10:38:55 bsd-14 kernel: maxdelay=3D0 > Jul 10 10:38:55 bsd-14 kernel: ql0: lacpdu receive > Jul 10 10:38:55 bsd-14 kernel: = actor=3D(8000,00-0E-1E-04-2C-F0,0213,8000,000E) > Jul 10 10:38:55 bsd-14 kernel: = actor.state=3D3d > Jul 10 10:38:55 bsd-14 kernel: = partner=3D(8000,00-0E-1E-08-05-20,01D3,8000,000C) > Jul 10 10:38:55 bsd-14 kernel: = partner.state=3D1d > Jul 10 10:38:55 bsd-14 kernel: maxdelay=3D0 > Jul 10 10:38:55 bsd-14 kernel: ql0: old pstate = d > Jul 10 10:38:55 bsd-14 kernel: ql0: new pstate = 3d > Jul 10 10:38:56 bsd-14 kernel: ql0: enable distributing on aggregator = [(8000,00-0E-1E-08-05-20,01D3,0000,0000),(8000,00-0E-1E-04-2C-F0,0213,0000= ,0000)], nports 0 -> 1 > Jul 10 10:38:56 bsd-14 kernel: lacp_select_active_aggregator: > Jul 10 10:38:56 bsd-14 kernel: = [(8000,00-0E-1E-08-05-20,01D3,0000,0000),(FFFF,00-00-00-00-00-00,0000,0000= ,0000)], speed=3D10000000000, nports=3D1 > Jul 10 10:38:56 bsd-14 kernel: = [(8000,00-0E-1E-08-05-20,01D3,0000,0000),(8000,00-0E-1E-04-2C-F0,0213,0000= ,0000)], speed=3D10000000000, nports=3D1 > Jul 10 10:38:56 bsd-14 kernel: active aggregator changed > Jul 10 10:38:56 bsd-14 kernel: old = [(8000,00-0E-1E-08-05-20,01D3,0000,0000),(FFFF,00-00-00-00-00-00,0000,0000= ,0000)] > Jul 10 10:38:56 bsd-14 kernel: new = [(8000,00-0E-1E-08-05-20,01D3,0000,0000),(8000,00-0E-1E-04-2C-F0,0213,0000= ,0000)] > Jul 10 10:38:56 bsd-14 kernel: Set table 0 with 1 ports > Jul 10 10:38:56 bsd-14 kernel: lacp_suppress_distributing > Jul 10 10:38:56 bsd-14 kernel: ql1: marker transmit, port=3D13, = sys=3D00:0e:1e:08:05:20, id=3D2 > Jul 10 10:38:56 bsd-14 kernel: ql0: marker transmit, port=3D12, = sys=3D00:0e:1e:08:05:20, id=3D2 > Jul 10 10:38:56 bsd-14 kernel: ql0: mux_state 3 -> 4 > Jul 10 10:38:56 bsd-14 kernel: ql0: marker response, port=3D12, = sys=3D00:0e:1e:08:05:20, id=3D2 > Jul 10 10:38:59 bsd-14 kernel: lacp_transit_expire > ^C >=20 >=20 >=20 >=20 > System 2 logs : >=20 > Jul 10 02:38:24 bsd-15 kernel: lacp_attach[738] : lacp attached > Jul 10 02:38:24 bsd-15 kernel: lacp_attach[740] : lacp_defined > Jul 10 02:38:24 bsd-15 kernel: lagg0: link state changed to UP > Jul 10 02:38:24 bsd-15 kernel: ql0: media changed 0x0 -> 0x100033, = ether =3D 1, fdx =3D 1, link =3D 1 > Jul 10 02:38:24 bsd-15 kernel: ql0: -> UNSELECTED > Jul 10 02:38:24 bsd-15 kernel: ql1: media changed 0x0 -> 0x100033, = ether =3D 1, fdx =3D 1, link =3D 1 > Jul 10 02:38:24 bsd-15 kernel: ql1: -> UNSELECTED > Jul 10 02:38:24 bsd-15 kernel: lacp_select_tx_port: no active = aggregator > Jul 10 02:38:25 bsd-15 kernel: ql1: port = lagid=3D[(8000,00-0E-1E-04-2C-F0,0213,8000,000F),(0000,00-00-00-00-00-00,0= 000,0000,0000)] > Jul 10 02:38:25 bsd-15 kernel: ql1: aggregator created > Jul 10 02:38:25 bsd-15 kernel: ql1: aggregator = lagid=3D[(8000,00-0E-1E-04-2C-F0,0213,0000,0000),(0000,00-00-00-00-00-00,0= 000,0000,0000)] > Jul 10 02:38:25 bsd-15 kernel: ql1: mux_state 0 -> 1 > Jul 10 02:38:25 bsd-15 kernel: ql0: port = lagid=3D[(8000,00-0E-1E-04-2C-F0,0213,8000,000E),(0000,00-00-00-00-00-00,0= 000,0000,0000)] > Jul 10 02:38:25 bsd-15 kernel: ql0: aggregator created > Jul 10 02:38:25 bsd-15 kernel: ql0: aggregator = lagid=3D[(8000,00-0E-1E-04-2C-F0,0213,0000,0000),(0000,00-00-00-00-00-00,0= 000,0000,0000)] > Jul 10 02:38:25 bsd-15 kernel: ql0: mux_state 0 -> 1 > Jul 10 02:38:26 bsd-15 kernel: ql0: lacpdu receive > Jul 10 02:38:26 bsd-15 kernel: = actor=3D(8000,00-0E-1E-08-05-20,01D3,8000,000C) > Jul 10 02:38:26 bsd-15 kernel: = actor.state=3D85 > Jul 10 02:38:26 bsd-15 kernel: = partner=3D(0000,00-00-00-00-00-00,0000,0000,0000) > Jul 10 02:38:26 bsd-15 kernel: partner.state=3D2 > Jul 10 02:38:26 bsd-15 kernel: maxdelay=3D0 > Jul 10 02:38:26 bsd-15 kernel: ql0: lacp_sm_rx_update_ntt: assert ntt > Jul 10 02:38:26 bsd-15 kernel: ql0: old pstate 2 > Jul 10 02:38:26 bsd-15 kernel: ql0: new pstate = 85 > Jul 10 02:38:26 bsd-15 kernel: ql0: partner timeout changed > Jul 10 02:38:26 bsd-15 kernel: ql0: lacpdu transmit > Jul 10 02:38:26 bsd-15 kernel: = actor=3D(8000,00-0E-1E-04-2C-F0,0213,8000,000E) > Jul 10 02:38:26 bsd-15 kernel: actor.state=3D5 > Jul 10 02:38:26 bsd-15 kernel: = partner=3D(8000,00-0E-1E-08-05-20,01D3,8000,000C) > Jul 10 02:38:26 bsd-15 kernel: = partner.state=3D85 > Jul 10 02:38:26 bsd-15 kernel: maxdelay=3D0 > Jul 10 02:38:26 bsd-15 kernel: ql1: lacpdu transmit > Jul 10 02:38:26 bsd-15 kernel: = actor=3D(8000,00-0E-1E-04-2C-F0,0213,8000,000F) > Jul 10 02:38:26 bsd-15 kernel: = actor.state=3D85 > Jul 10 02:38:26 bsd-15 kernel: = partner=3D(0000,00-00-00-00-00-00,0000,0000,0000) > Jul 10 02:38:26 bsd-15 kernel: partner.state=3D2 > Jul 10 02:38:26 bsd-15 kernel: maxdelay=3D0 > Jul 10 02:38:26 bsd-15 kernel: ql0: collecting disabled > Jul 10 02:38:26 bsd-15 kernel: lacp_aggregator_delref: = lagid=3D[(8000,00-0E-1E-04-2C-F0,0213, = 0000,0000),(0000,00-00-00-00-00-00,0000,0000,0000)], refcnt 1 -> 0 >=20 > Jul 10 02:38:26 bsd-15 kernel: ql0: mux_state 1 -> 0 > Jul 10 02:38:26 bsd-15 kernel: ql0: lacpdu transmit > Jul 10 02:38:26 bsd-15 kernel: = actor=3D(8000,00-0E-1E-04-2C-F0,0213,8000,000E) > Jul 10 02:38:26 bsd-15 kernel: actor.state=3D5 > Jul 10 02:38:26 bsd-15 kernel: = partner=3D(8000,00-0E-1E-08-05-20,01D3,8000,000C) > Jul 10 02:38:26 bsd-15 kernel: = partner.state=3D85 > Jul 10 02:38:26 bsd-15 kernel: maxdelay=3D0 > Jul 10 02:38:27 bsd-15 kernel: ql0: lacpdu receive > Jul 10 02:38:27 bsd-15 kernel: = actor=3D(8000,00-0E-1E-08-05-20,01D3,8000,000C) > Jul 10 02:38:27 bsd-15 kernel: actor.state=3D5 > Jul 10 02:38:27 bsd-15 kernel: = partner=3D(8000,00-0E-1E-04-2C-F0,0213,8000,000E) > Jul 10 02:38:27 bsd-15 kernel: partner.state=3D5 > Jul 10 02:38:27 bsd-15 kernel: maxdelay=3D0 > Jul 10 02:38:27 bsd-15 kernel: ql0: old pstate = 85 > Jul 10 02:38:27 bsd-15 kernel: ql0: new pstate 5 > Jul 10 02:38:27 bsd-15 kernel: ql1: lacp_sm_rx_timer: EXPIRED -> = DEFAULTED > Jul 10 02:38:27 bsd-15 kernel: ql1: partner timeout changed > Jul 10 02:38:27 bsd-15 kernel: ql1: lacp_sm_mux_timer: aggregator = [(8000,00-0E-1E-04-2C-F0, = 0213,0000,0000),(0000,00-00-00-00-00-00,0000,0000,0000)], pending 1 -> 0 > Jul 10 02:38:27 bsd-15 kernel: ql1: collecting disabled > Jul 10 02:38:27 bsd-15 kernel: lacp_aggregator_delref: = lagid=3D[(8000,00-0E-1E-04-2C-F0,0213, = 0000,0000),(0000,00-00-00-00-00-00,0000,0000,0000)], refcnt 1 -> 0 >=20 > Jul 10 02:38:27 bsd-15 kernel: ql1: mux_state 1 -> 0 > Jul 10 02:38:27 bsd-15 kernel: ql1: lacpdu transmit > Jul 10 02:38:27 bsd-15 kernel: = actor=3D(8000,00-0E-1E-04-2C-F0,0213,8000,000F) > Jul 10 02:38:27 bsd-15 kernel: = actor.state=3D45 > Jul 10 02:38:27 bsd-15 kernel: = partner=3D(FFFF,00-00-00-00-00-00,0000,FFFF,0000) > Jul 10 02:38:27 bsd-15 kernel: = partner.state=3D3c > Jul 10 02:38:27 bsd-15 kernel: maxdelay=3D0 > Jul 10 02:38:27 bsd-15 kernel: ql0: port = lagid=3D[(8000,00-0E-1E-04-2C-F0,0213,8000,000E),(8000,00-0E-1E-08-05-20,0= 1D3,8000,000C)] > Jul 10 02:38:27 bsd-15 kernel: ql0: aggregator created > Jul 10 02:38:27 bsd-15 kernel: ql0: aggregator = lagid=3D[(8000,00-0E-1E-04-2C-F0,0213,0000,0000),(8000,00-0E-1E-08-05-20,0= 1D3,0000,0000)] > Jul 10 02:38:27 bsd-15 kernel: ql0: mux_state 0 -> 1 > Jul 10 02:38:28 bsd-15 kernel: ql1: port = lagid=3D[(8000,00-0E-1E-04-2C-F0,0213,8000,000F),(FFFF,00-00-00-00-00-00,0= 000,FFFF,0000)] > Jul 10 02:38:28 bsd-15 kernel: ql1: aggregator created > Jul 10 02:38:28 bsd-15 kernel: ql1: aggregator = lagid=3D[(8000,00-0E-1E-04-2C-F0,0213,0000,0000),(FFFF,00-00-00-00-00-00,0= 000,0000,0000)] > Jul 10 02:38:28 bsd-15 kernel: ql1: mux_state 0 -> 1 > Jul 10 02:38:29 bsd-15 kernel: ql0: lacp_sm_mux_timer: aggregator = [(8000,00-0E-1E-04-2C-F0, = 0213,0000,0000),(8000,00-0E-1E-08-05-20,01D3,0000,0000)], pending 1 -> 0 > Jul 10 02:38:29 bsd-15 kernel: ql0: collecting disabled > Jul 10 02:38:29 bsd-15 kernel: ql0: mux_state 1 -> 2 > Jul 10 02:38:29 bsd-15 kernel: ql0: lacpdu transmit > Jul 10 02:38:29 bsd-15 kernel: = actor=3D(8000,00-0E-1E-04-2C-F0,0213,8000,000E) > Jul 10 02:38:29 bsd-15 kernel: = actor.state=3Dd > Jul 10 02:38:29 bsd-15 kernel: = partner=3D(8000,00-0E-1E-08-05-20,01D3,8000,000C) > Jul 10 02:38:29 bsd-15 kernel: partner.state=3D5 > Jul 10 02:38:29 bsd-15 kernel: maxdelay=3D0 > Jul 10 02:38:30 bsd-15 kernel: ql0: lacpdu receive > Jul 10 02:38:30 bsd-15 kernel: = actor=3D(8000,00-0E-1E-08-05-20,01D3,8000,000C) > Jul 10 02:38:30 bsd-15 kernel: = actor.state=3D1d > Jul 10 02:38:30 bsd-15 kernel: = partner=3D(8000,00-0E-1E-04-2C-F0,0213,8000,000E) > Jul 10 02:38:30 bsd-15 kernel: = partner.state=3Dd > Jul 10 02:38:30 bsd-15 kernel: maxdelay=3D0 > Jul 10 02:38:30 bsd-15 kernel: ql0: old pstate 5 > Jul 10 02:38:30 bsd-15 kernel: ql0: new pstate = 1d > Jul 10 02:38:30 bsd-15 kernel: ql1: lacp_sm_mux_timer: aggregator = [(8000,00-0E-1E-04-2C-F0, = 0213,0000,0000),(FFFF,00-00-00-00-00-00,0000,0000,0000)], pending 1 -> 0 > Jul 10 02:38:30 bsd-15 kernel: ql1: collecting disabled > Jul 10 02:38:30 bsd-15 kernel: ql1: mux_state 1 -> 2 > Jul 10 02:38:30 bsd-15 kernel: ql1: collecting enabled > Jul 10 02:38:30 bsd-15 kernel: ql1: mux_state 2 -> 3 > Jul 10 02:38:30 bsd-15 kernel: ql1: enable distributing on aggregator = [(8000,00-0E-1E-04-2C-F0,0213,0000,0000),(FFFF,00-00-00-00-00-00,0000,0000= ,0000)], nports 0 -> 1 > Jul 10 02:38:30 bsd-15 kernel: lacp_select_active_aggregator: > Jul 10 02:38:30 bsd-15 kernel: = [(8000,00-0E-1E-04-2C-F0,0213,0000,0000),(FFFF,00-00-00-00-00-00,0000,0000= ,0000)], speed=3D10000000000, nports=3D1 > Jul 10 02:38:30 bsd-15 kernel: active aggregator changed > Jul 10 02:38:30 bsd-15 kernel: old (none) > Jul 10 02:38:30 bsd-15 kernel: new = [(8000,00-0E-1E-04-2C-F0,0213,0000,0000),(FFFF,00-00-00 = 00-00-00,0000,0000,0000)] > Jul 10 02:38:30 bsd-15 kernel: Set table 1 with 1 ports > Jul 10 02:38:30 bsd-15 kernel: lacp_suppress_distributing > Jul 10 02:38:30 bsd-15 kernel: ql1: marker transmit, port=3D15, = sys=3D00:0e:1e:04:2c:f0, id=3D1 > Jul 10 02:38:30 bsd-15 kernel: ql0: marker transmit, port=3D14, = sys=3D00:0e:1e:04:2c:f0, id=3D1 > Jul 10 02:38:30 bsd-15 kernel: ql1: mux_state 3 -> 4 > Jul 10 02:38:30 bsd-15 kernel: ql1: lacpdu transmit > Jul 10 02:38:30 bsd-15 kernel: ql0: marker response, port=3D14, = sys=3D00:0e:1e:04:2c:f0, id=3D1 > Jul 10 02:38:30 bsd-15 kernel: = actor=3D(8000,00-0E-1E-04-2C-F0,0213,8000,000F) > Jul 10 02:38:30 bsd-15 kernel: = actor.state=3D7d > Jul 10 02:38:30 bsd-15 kernel: = partner=3D(FFFF,00-00-00-00-00-00,0000,FFFF,0000) > Jul 10 02:38:30 bsd-15 kernel: = partner.state=3D3c > Jul 10 02:38:30 bsd-15 kernel: maxdelay=3D0 > Jul 10 02:38:30 bsd-15 kernel: ql0: collecting enabled > Jul 10 02:38:30 bsd-15 kernel: ql0: mux_state 2 -> 3 > Jul 10 02:38:30 bsd-15 kernel: ql0: enable distributing on aggregator = [(8000,00-0E-1E-04-2C-F0,0213,0000,0000),(8000,00-0E-1E-08-05-20,01D3,0000= ,0000)], nports 0 -> 1 > Jul 10 02:38:30 bsd-15 kernel: lacp_select_active_aggregator: > Jul 10 02:38:30 bsd-15 kernel: = [(8000,00-0E-1E-04-2C-F0,0213,0000,0000),(8000,00-0E-1E-08-05-20,01D3,0000= ,0000)], speed=3D10000000000, nports=3D1 > Jul 10 02:38:30 bsd-15 kernel: = [(8000,00-0E-1E-04-2C-F0,0213,0000,0000),(FFFF,00-00-00-00-00-00,0000,0000= ,0000)], speed=3D10000000000, nports=3D1 > Jul 10 02:38:30 bsd-15 kernel: active aggregator not changed > Jul 10 02:38:30 bsd-15 kernel: new = [(8000,00-0E-1E-04-2C-F0,0213,0000,0000),(FFFF,00-00-00-00-00-00,0000,0000= ,0000)] > Jul 10 02:38:30 bsd-15 kernel: ql0: mux_state 3 -> 4 > Jul 10 02:38:30 bsd-15 kernel: ql0: lacpdu transmit > Jul 10 02:38:30 bsd-15 kernel: = actor=3D(8000,00-0E-1E-04-2C-F0,0213,8000,000E) > Jul 10 02:38:30 bsd-15 kernel: = actor.state=3D3d > Jul 10 02:38:30 bsd-15 kernel: = partner=3D(8000,00-0E-1E-08-05-20,01D3,8000,000C) > Jul 10 02:38:30 bsd-15 kernel: = partner.state=3D1d > Jul 10 02:38:30 bsd-15 kernel: maxdelay=3D0 > Jul 10 02:38:33 bsd-15 kernel: lacp_transit_expire > ^C >=20 > Let me know if you need more info. >=20 > Thanks > Adarsh >=20 >=20 > -----Original Message----- > From: owner-freebsd-net@freebsd.org = [mailto:owner-freebsd-net@freebsd.org] On Behalf Of Adarsh Joshi > Sent: Tuesday, July 10, 2012 10:08 AM > To: Andrew Boyer > Cc: freebsd-net@freebsd.org > Subject: RE: lacp lagg port flags do not show correctly resulting in = poor traffic distribution/performance >=20 > Andrew, >=20 > Thanks for the reply. >=20 > The reason for my suspicion on the portflags is thus (extracted from = the ifconfig output in my previous mail): >=20 > System 1: > Laggport: ql1 flags =3D 18 state =3D 7D > Laggport: ql0 flags =3D 1c state =3D 3D >=20 > System 2: > Laggport: ql1 flags =3D 1c state =3D 7D > Laggport: ql0 flags =3D 18 state =3D 3D >=20 > I should have explained my setup to you before. Here it is. > Both the ql0 interfaces of the 2 systems are connected using a single = cable and ql1 interfaces of the 2 systems are connected using a single = cable. >=20 > System 1 System 2 > ql0 <=3D=3D=3D=3D=3D=3D=3D> ql0 > ql1 <=3D=3D=3D=3D=3D=3D=3D> ql1 >=20 > With this setup, I don't think it is possible for ports ql0 to talk to = their partners (each other) and ql1 ports not getting a response from = their partner and still get the lagg configuration I have posted. >=20 > I thought the portflags are dependent on the LACP state. But I see = different flags for the same LACP state (For the state 7D, ql1 on system = 1 shows flags =3D 18 and ql1 on system 2 shows flags =3D 1c). >=20 > Or is my understanding totally wrong? >=20 > I will send the LACP_DEBUG logs within the hour. >=20 > Thanks > Adarsh >=20 > From: Andrew Boyer [mailto:aboyer@averesystems.com] > Sent: Tuesday, July 10, 2012 5:57 AM > To: Adarsh Joshi > Cc: freebsd-net@freebsd.org > Subject: Re: lacp lagg port flags do not show correctly resulting in = poor traffic distribution/performance >=20 >=20 > On Jul 9, 2012, at 8:38 PM, Adarsh Joshi wrote: >=20 >=20 > Hi, >=20 > I am trying to configure lacp lagg interfaces with 2 systems connected = back to back as follows: >=20 > Ifconfig lagg0 create > Ifconfig lagg0 laggproto lacp laggport ql0 laggport ql1 192.168.100.1 = netmask 255.255.255.0 >=20 > Sometimes, the lag interface comes up correctly but sometimes the = laggport flags do not show properly. Instead of = 1c, it shows values of 18. I have seen = similar issues reported on various forums with no solution. > Looking at the lagg driver code and reading the standard, I thought = the laggport flags ( defined in if_lagg.h) are based on the = LACP_STATE_BITS in file ieee8023ad_lacp.h. But the following ifconfig -v = output does not make any sense to me. >=20 > My concern is that when all the interfaces show flags as 1c, the = traffic is distributed across both the interfaces uniformly and I get = aggregated throughput. If not, the traffic flows only on 1 interface. >=20 > Is this a bug? How do I solve this? Or am I doing something wrong? >=20 > I am using Free-BSD 9.0 release. >=20 > System 1: > # ifconfig -v lagg0 > lag id: [(8000,00-0E-1E-08-05-20,0213,0000,0000), > (8000,00-0E-1E-04-2C-F0,0213,0000,0000)] > laggport: ql1 flags=3D18 state=3D7D > [(8000,00-0E-1E-08-05-20,0213,8000,000F), > (FFFF,00-00-00-00-00-00,0000,FFFF,0000)] > laggport: ql0 flags=3D1c = state=3D3D > [(8000,00-0E-1E-08-05-20,0213,8000,000E), > (8000,00-0E-1E-04-2C-F0,0213,8000,000E)] >=20 > System 2: >=20 > # ifconfig -v lagg0 > lag id: [(8000,00-0E-1E-04-2C-F0,0213,0000,0000), > (FFFF,00-00-00-00-00-00,0000,0000,0000)] > laggport: ql1 flags=3D1c = state=3D7D > [(8000,00-0E-1E-04-2C-F0,0213,8000,000F), > (FFFF,00-00-00-00-00-00,0000,FFFF,0000)] > laggport: ql0 flags=3D18 state=3D3D > [(8000,00-0E-1E-04-2C-F0,0213,8000,000E), > (8000,00-0E-1E-08-05-20,0213,8000,000E)] >=20 >=20 > thanks > Adarsh >=20 > I don't think you have a port flags problem per se; the flags are = correctly displaying the state of the lagg. Your problem is that your = systems aren't negotiating the correct lagg configuration. Each tuple = after the laggport represents the [(actor state),(partner state)]. = Ports ql0 have been able to talk to their partners (each other). = Neither ql1 port has seen a response from a partner, though. >=20 > You could try restarting the state machine on one box with 'ifconfig = lagg0 laggproto lacp'. To see the negotiation you'll need to rebuild = your kernel with '#define LACP_DEBUG 1' added to the top of = sys/net/ieee802.3ad_lacp.c. Or upgrade to a newer stable snapshot that = has the net.lacp_debug sysctl and turn it on. >=20 > Or just turn off LACP. What does it get you in this configuration? >=20 > Hope this helps, > Andrew >=20 > -------------------------------------------------- > Andrew Boyer = aboyer@averesystems.com >=20 >=20 >=20 >=20 >=20 > ________________________________ > This message and any attached documents contain information from = QLogic Corporation or its wholly-owned subsidiaries that may be = confidential. If you are not the intended recipient, you may not read, = copy, distribute, or use this information. If you have received this = transmission in error, please notify the sender immediately by reply = e-mail and then delete this message. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >=20 >=20 > This message and any attached documents contain information from = QLogic Corporation or its wholly-owned subsidiaries that may be = confidential. If you are not the intended recipient, you may not read, = copy, distribute, or use this information. If you have received this = transmission in error, please notify the sender immediately by reply = e-mail and then delete this message. >=20 -------------------------------------------------- Andrew Boyer aboyer@averesystems.com From owner-freebsd-net@FreeBSD.ORG Fri Jul 27 16:16:46 2012 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 BB220106566B for ; Fri, 27 Jul 2012 16:16:46 +0000 (UTC) (envelope-from adarsh.joshi@qlogic.com) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe003.messaging.microsoft.com [216.32.180.186]) by mx1.freebsd.org (Postfix) with ESMTP id 757AE8FC1B for ; Fri, 27 Jul 2012 16:16:46 +0000 (UTC) Received: from mail42-co1-R.bigfish.com (10.243.78.231) by CO1EHSOBE011.bigfish.com (10.243.66.74) with Microsoft SMTP Server id 14.1.225.23; Fri, 27 Jul 2012 16:16:40 +0000 Received: from mail42-co1 (localhost [127.0.0.1]) by mail42-co1-R.bigfish.com (Postfix) with ESMTP id 02C845C028F; Fri, 27 Jul 2012 16:16:40 +0000 (UTC) X-Forefront-Antispam-Report: CIP:198.70.193.64; KIP:(null); UIP:(null); IPV:NLI; H:avexcashub1.qlogic.com; RD:avexcashub2.qlogic.com; EFVD:NLI X-SpamScore: -18 X-BigFish: VPS-18(zz98dI9371I936eI542M1432I1453M1447I328cMzz1202hzz8275bh8275dh74efjz2fh2a8h668h839h944hd25hf0ah107ah) Received-SPF: pass (mail42-co1: domain of qlogic.com designates 198.70.193.64 as permitted sender) client-ip=198.70.193.64; envelope-from=adarsh.joshi@qlogic.com; helo=avexcashub1.qlogic.com ; 1.qlogic.com ; Received: from mail42-co1 (localhost.localdomain [127.0.0.1]) by mail42-co1 (MessageSwitch) id 1343405797471223_8429; Fri, 27 Jul 2012 16:16:37 +0000 (UTC) Received: from CO1EHSMHS023.bigfish.com (unknown [10.243.78.249]) by mail42-co1.bigfish.com (Postfix) with ESMTP id 7107C6C028A; Fri, 27 Jul 2012 16:16:37 +0000 (UTC) Received: from avexcashub1.qlogic.com (198.70.193.64) by CO1EHSMHS023.bigfish.com (10.243.66.33) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 27 Jul 2012 16:16:36 +0000 Received: from avexmb1.qlogic.org ([fe80::9545:3a4f:c131:467d]) by avexcashub2.qlogic.org ([::1]) with mapi; Fri, 27 Jul 2012 09:16:35 -0700 From: Adarsh Joshi To: Andrew Boyer Date: Fri, 27 Jul 2012 09:14:55 -0700 Thread-Topic: lacp lagg port flags do not show correctly resulting in poor traffic distribution/performance Thread-Index: Ac1sCiabdQPmokAcR5SWpvdfGzlB3wACM8L/ Message-ID: <5E4F49720D0BAD499EE1F01232234BA87742F8ABF8@AVEXMB1.qlogic.org> References: <5E4F49720D0BAD499EE1F01232234BA877435B2E28@AVEXMB1.qlogic.org> <4C5FC147-2F49-4AE0-ADF3-C5381DE6580F@averesystems.com> <5E4F49720D0BAD499EE1F01232234BA877435B2F2E@AVEXMB1.qlogic.org> <5E4F49720D0BAD499EE1F01232234BA877435B2F66@AVEXMB1.qlogic.org>, <9BC66C40-6F4B-48A0-AEC0-DCAD0C6863EF@averesystems.com> In-Reply-To: <9BC66C40-6F4B-48A0-AEC0-DCAD0C6863EF@averesystems.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: qlogic.com Cc: "freebsd-net@freebsd.org" Subject: RE: lacp lagg port flags do not show correctly resulting in poor traffic distribution/performance 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, 27 Jul 2012 16:16:46 -0000 Andrew, Thanks for the response. Yes, the link is working fine. I am able to see LA= CPDUs on tcpdump. regards Adarsh ________________________________________ From: Andrew Boyer [aboyer@averesystems.com] Sent: Friday, July 27, 2012 8:11 AM To: Adarsh Joshi Cc: freebsd-net@freebsd.org Subject: Re: lacp lagg port flags do not show correctly resulting in poor t= raffic distribution/performance Adarsh, Sorry for the delay. I'm not an LACP protocol expert, but looking at your logs I don't see ql1 o= n either node receiving a lacpdu response. Are you certain that link is wo= rking? -Andrew On Jul 10, 2012, at 1:53 PM, Adarsh Joshi wrote: > Andrew, > > Here are the logs with LACP_DEBUG defined in ieee802.3ad_lacp.c, > > after typing > > Ifconfig lagg0 create > ifconfig lagg0 laggproto lacp laggport ql0 laggport ql1 192.168.100.1 net= mask 255.255.255.0 > > I compiled it as a standalone driver by the way. > > System 1: > > # ifconfig -v lagg0 > lagg0: flags=3D8843 metric 0 mtu = 1500 > options=3D13b > ether 00:0e:1e:08:05:20 > inet 192.168.100.1 netmask 0xffffff00 broadcast 192.168.100.255 > nd6 options=3D29 > media: Ethernet autoselect > status: active > groups: lagg > laggproto lacp > lag id: [(8000,00-0E-1E-08-05-20,01D3,0000,0000), > (8000,00-0E-1E-04-2C-F0,0213,0000,0000)] > laggport: ql1 flags=3D18 state=3D7D > [(8000,00-0E-1E-08-05-20,01D3,8000,000D), > (FFFF,00-00-00-00-00-00,0000,FFFF,0000)] > laggport: ql0 flags=3D1c state=3D3= D > [(8000,00-0E-1E-08-05-20,01D3,8000,000C), > (8000,00-0E-1E-04-2C-F0,0213,8000,000E)] > > > System 2: > > # ifconfig -v lagg0 > lagg0: flags=3D8843 metric 0 mtu = 1500 > options=3D13b > ether 00:0e:1e:04:2c:f0 > inet 192.168.100.2 netmask 0xffffff00 broadcast 192.168.100.255 > nd6 options=3D29 > media: Ethernet autoselect > status: active > groups: lagg > laggproto lacp > lag id: [(8000,00-0E-1E-04-2C-F0,0213,0000,0000), > (FFFF,00-00-00-00-00-00,0000,0000,0000)] > laggport: ql1 flags=3D1c state=3D7= D > [(8000,00-0E-1E-04-2C-F0,0213,8000,000F), > (FFFF,00-00-00-00-00-00,0000,FFFF,0000)] > laggport: ql0 flags=3D18 state=3D3D > [(8000,00-0E-1E-04-2C-F0,0213,8000,000E), > (8000,00-0E-1E-08-05-20,01D3,8000,000C)] > > > System 1 logs : > > Jul 10 10:38:49 bsd-14 kernel: lacp_attach[738] : lacp attached > Jul 10 10:38:49 bsd-14 kernel: lacp_attach[740] : lacp_defined > Jul 10 10:38:49 bsd-14 kernel: lagg0: link state changed to UP > Jul 10 10:38:49 bsd-14 kernel: ql0: media changed 0x0 -> 0x100033, ether = =3D 1, fdx =3D 1, link =3D 1 > Jul 10 10:38:49 bsd-14 kernel: ql0: -> UNSELECTED > Jul 10 10:38:49 bsd-14 kernel: ql1: media changed 0x0 -> 0x100033, ether = =3D 1, fdx =3D 1, link =3D 1 > Jul 10 10:38:49 bsd-14 kernel: ql1: -> UNSELECTED > Jul 10 10:38:49 bsd-14 kernel: lacp_select_tx_port: no active aggregator > Jul 10 10:38:50 bsd-14 kernel: ql1: port lagid=3D[(8000,00-0E-1E-08-05-20= ,01D3,8000,000D),(0000,00-00-00-00-00-00,0000,0000,0000)] > Jul 10 10:38:50 bsd-14 kernel: ql1: aggregator created > Jul 10 10:38:50 bsd-14 kernel: ql1: aggregator lagid=3D[(8000,00-0E-1E-08= -05-20,01D3,0000,0000),(0000,00-00-00-00-00-00,0000,0000,0000)] > Jul 10 10:38:50 bsd-14 kernel: ql1: mux_state 0 -> 1 > Jul 10 10:38:50 bsd-14 kernel: ql0: port lagid=3D[(8000,00-0E-1E-08-05-20= ,01D3,8000,000C),(0000,00-00-00-00-00-00,0000,0000,0000)] > Jul 10 10:38:50 bsd-14 kernel: ql0: aggregator created > Jul 10 10:38:50 bsd-14 kernel: ql0: aggregator lagid=3D[(8000,00-0E-1E-08= -05-20,01D3,0000,0000),(0000,00-00-00-00-00-00,0000,0000,0000)] > Jul 10 10:38:50 bsd-14 kernel: ql0: mux_state 0 -> 1 > Jul 10 10:38:51 bsd-14 kernel: ql1: lacpdu transmit > Jul 10 10:38:51 bsd-14 kernel: actor=3D(8000,00-0E-1E-08-05-20,01D3,8000,= 000D) > Jul 10 10:38:51 bsd-14 kernel: actor.state=3D85 > Jul 10 10:38:51 bsd-14 kernel: partner=3D(0000,00-00-00-00-00-00,0000,000= 0,0000) > Jul 10 10:38:51 bsd-14 kernel: partner.state=3D2 > Jul 10 10:38:51 bsd-14 kernel: maxdelay=3D0 > Jul 10 10:38:51 bsd-14 kernel: ql0: lacpdu transmit > Jul 10 10:38:51 bsd-14 kernel: actor=3D(8000,00-0E-1E-08-05-20,01D3,8000,= 000C) > Jul 10 10:38:51 bsd-14 kernel: actor.state=3D85 > Jul 10 10:38:51 bsd-14 kernel: partner=3D(0000,00-00-00-00-00-00,0000,000= 0,0000) > Jul 10 10:38:51 bsd-14 kernel: partner.state=3D2 > Jul 10 10:38:51 bsd-14 kernel: maxdelay=3D0 > Jul 10 10:38:51 bsd-14 kernel: ql0: lacpdu receive > Jul 10 10:38:51 bsd-14 kernel: actor=3D(8000,00-0E-1E-04-2C-F0,0213,8000,= 000E) > Jul 10 10:38:51 bsd-14 kernel: actor.state=3D5 > Jul 10 10:38:51 bsd-14 kernel: partner=3D(8000,00-0E-1E-08-05-20,01D3,800= 0,000C) > Jul 10 10:38:51 bsd-14 kernel: partner.state=3D85 > Jul 10 10:38:51 bsd-14 kernel: maxdelay=3D0 > Jul 10 10:38:51 bsd-14 kernel: ql0: old pstate 2 > Jul 10 10:38:51 bsd-14 kernel: ql0: new pstate 5 > Jul 10 10:38:51 bsd-14 kernel: ql0: partner timeout changed > Jul 10 10:38:51 bsd-14 kernel: ql0: lacpdu receive > Jul 10 10:38:51 bsd-14 kernel: actor=3D(8000,00-0E-1E-04-2C-F0,0213,8000,= 000E) > Jul 10 10:38:51 bsd-14 kernel: actor.state=3D5 > Jul 10 10:38:51 bsd-14 kernel: partner=3D(8000,00-0E-1E-08-05-20,01D3,800= 0,000C) > Jul 10 10:38:51 bsd-14 kernel: partner.state=3D85 > Jul 10 10:38:51 bsd-14 kernel: maxdelay=3D0 > Jul 10 10:38:52 bsd-14 kernel: ql1: lacp_sm_rx_timer: EXPIRED -> DEFAULTE= D > Jul 10 10:38:52 bsd-14 kernel: ql1: partner timeout changed > Jul 10 10:38:52 bsd-14 kernel: ql1: lacp_sm_mux_timer: aggregator [(8000,= 00-0E-1E-08-05-20,01D3,0000,0000),(0000,00-00-00-00-00-00,0000,0000,0000)],= pending 1 -> 0 > Jul 10 10:38:52 bsd-14 kernel: ql1: collecting disabled > Jul 10 10:38:52 bsd-14 kernel: lacp_aggregator_delref: lagid=3D[(8000,00-= 0E-1E-08-05-20,01D3,0000,0000),(0000,00-00-00-00-00-00,0000,0000,0000)], re= fcnt 1 -> 0 > Jul 10 10:38:52 bsd-14 kernel: ql1: mux_state 1 -> 0 > Jul 10 10:38:52 bsd-14 kernel: ql1: lacpdu transmit > Jul 10 10:38:52 bsd-14 kernel: actor=3D(8000,00-0E-1E-08-05-20,01D3,8000,= 000D) > Jul 10 10:38:52 bsd-14 kernel: actor.state=3D45 > Jul 10 10:38:52 bsd-14 kernel: partner=3D(FFFF,00-00-00-00-00-00,0000,FFF= F,0000) > Jul 10 10:38:52 bsd-14 kernel: partner.state=3D3c > Jul 10 10:38:52 bsd-14 kernel: maxdelay=3D0 > Jul 10 10:38:52 bsd-14 kernel: ql0: lacp_sm_mux_timer: aggregator [(8000,= 00-0E-1E-08-05-20,01D3,0000,0000),(0000,00-00-00-00-00-00,0000,0000,0000)],= pending 1 -> 0 > Jul 10 10:38:52 bsd-14 kernel: ql0: collecting disabled > Jul 10 10:38:52 bsd-14 kernel: lacp_aggregator_delref: lagid=3D[(8000,00-= 0E-1E-08-05-20,01D3,0000,0000),(0000,00-00-00-00-00-00,0000,0000,0000)], re= fcnt 1 -> 0 > Jul 10 10:38:52 bsd-14 kernel: ql0: mux_state 1 -> 0 > Jul 10 10:38:52 bsd-14 kernel: ql0: lacpdu transmit > Jul 10 10:38:52 bsd-14 kernel: actor=3D(8000,00-0E-1E-08-05-20,01D3,8000,= 000C) > Jul 10 10:38:52 bsd-14 kernel: actor.state=3D5 > Jul 10 10:38:52 bsd-14 kernel: partner=3D(8000,00-0E-1E-04-2C-F0,0213,800= 0,000E) > Jul 10 10:38:52 bsd-14 kernel: partner.state=3D5 > Jul 10 10:38:52 bsd-14 kernel: maxdelay=3D0 > Jul 10 10:38:53 bsd-14 kernel: ql1: port lagid=3D[(8000,00-0E-1E-08-05-20= ,01D3,8000,000D),(FFFF,00-00-00-00-00-00,0000,FFFF,0000)] > Jul 10 10:38:53 bsd-14 kernel: ql1: aggregator created > Jul 10 10:38:53 bsd-14 kernel: ql1: aggregator lagid=3D[(8000,00-0E-1E-08= -05-20,01D3,0000,0000),(FFFF,00-00-00-00-00-00,0000,0000,0000)] > Jul 10 10:38:53 bsd-14 kernel: ql1: mux_state 0 -> 1 > Jul 10 10:38:53 bsd-14 kernel: ql0: port lagid=3D[(8000,00-0E-1E-08-05-20= ,01D3,8000,000C),(8000,00-0E-1E-04-2C-F0,0213,8000,000E)] > Jul 10 10:38:53 bsd-14 kernel: ql0: aggregator created > Jul 10 10:38:53 bsd-14 kernel: ql0: aggregator lagid=3D[(8000,00-0E-1E-08= -05-20,01D3,0000,0000),(8000,00-0E-1E-04-2C-F0,0213,0000,0000)] > Jul 10 10:38:53 bsd-14 kernel: ql0: mux_state 0 -> 1 > Jul 10 10:38:54 bsd-14 kernel: ql0: lacpdu receive > Jul 10 10:38:54 bsd-14 kernel: actor=3D(8000,00-0E-1E-04-2C-F0,0213,8000,= 000E) > Jul 10 10:38:54 bsd-14 kernel: actor.state=3Dd > Jul 10 10:38:54 bsd-14 kernel: partner=3D(8000,00-0E-1E-08-05-20,01D3,800= 0,000C) > Jul 10 10:38:54 bsd-14 kernel: partner.state=3D5 > Jul 10 10:38:54 bsd-14 kernel: maxdelay=3D0 > Jul 10 10:38:54 bsd-14 kernel: ql0: old pstate 5 > Jul 10 10:38:54 bsd-14 kernel: ql0: new pstate d > Jul 10 10:38:55 bsd-14 kernel: ql1: lacp_sm_mux_timer: aggregator [(8000,= 00-0E-1E-08-05-20,01D3,0000,0000),(FFFF,00-00-00-00-00-00,0000,0000,0000)],= pending 1 -> 0 > Jul 10 10:38:55 bsd-14 kernel: ql1: collecting disabled > Jul 10 10:38:55 bsd-14 kernel: ql1: mux_state 1 -> 2 > Jul 10 10:38:55 bsd-14 kernel: ql1: collecting enabled > Jul 10 10:38:55 bsd-14 kernel: ql1: mux_state 2 -> 3 > Jul 10 10:38:55 bsd-14 kernel: ql1: enable distributing on aggregator [(8= 000,00-0E-1E-08-05-20,01D3,0000,0000),(FFFF,00-00-00-00-00-00,0000,0000,000= 0)], nports 0 -> 1 > Jul 10 10:38:55 bsd-14 kernel: lacp_select_active_aggregator: > Jul 10 10:38:55 bsd-14 kernel: [(8000,00-0E-1E-08-05-20,01D3,0000,0000),(= FFFF,00-00-00-00-00-00,0000,0000,0000)], speed=3D10000000000, nports=3D1 > Jul 10 10:38:55 bsd-14 kernel: active aggregator changed > Jul 10 10:38:55 bsd-14 kernel: old (none) > Jul 10 10:38:55 bsd-14 kernel: new [(8000,00-0E-1E-08-05-20,01D3,0000,000= 0),(FFFF,00-00-00-00-00-00,0000,0000,0000)] > Jul 10 10:38:55 bsd-14 kernel: Set table 1 with 1 ports > Jul 10 10:38:55 bsd-14 kernel: lacp_suppress_distributing > Jul 10 10:38:55 bsd-14 kernel: ql1: marker transmit, port=3D13, sys=3D00:= 0e:1e:08:05:20, id=3D1 > Jul 10 10:38:55 bsd-14 kernel: ql0: marker transmit, port=3D12, sys=3D00:= 0e:1e:08:05:20, id=3D1 > Jul 10 10:38:55 bsd-14 kernel: ql1: mux_state 3 -> 4 > Jul 10 10:38:55 bsd-14 kernel: ql1: lacpdu transmit > Jul 10 10:38:55 bsd-14 kernel: ql0: marker response, port=3D12, sys=3D00:= 0e:1e:08:05:20, id=3D1 > Jul 10 10:38:55 bsd-14 kernel: actor=3D(8000,00-0E-1E-08-05-20,01D3,8000,= 000D) > Jul 10 10:38:55 bsd-14 kernel: actor.state=3D7d > Jul 10 10:38:55 bsd-14 kernel: partner=3D(FFFF,00-00-00-00-00-00,0000,FFF= F,0000) > Jul 10 10:38:55 bsd-14 kernel: partner.state=3D3c > Jul 10 10:38:55 bsd-14 kernel: maxdelay=3D0 > Jul 10 10:38:55 bsd-14 kernel: ql0: lacp_sm_mux_timer: aggregator [(8000,= 00-0E-1E-08-05-20,01D3,0000,0000),(8000,00-0E-1E-04-2C-F0,0213,0000,0000)],= pending 1 -> 0 > Jul 10 10:38:55 bsd-14 kernel: ql0: collecting disabled > Jul 10 10:38:55 bsd-14 kernel: ql0: mux_state 1 -> 2 > Jul 10 10:38:55 bsd-14 kernel: ql0: collecting enabled > Jul 10 10:38:55 bsd-14 kernel: ql0: mux_state 2 -> 3 > Jul 10 10:38:55 bsd-14 kernel: ql0: lacpdu transmit > Jul 10 10:38:55 bsd-14 kernel: actor=3D(8000,00-0E-1E-08-05-20,01D3,8000,= 000C) > Jul 10 10:38:55 bsd-14 kernel: actor.state=3D1d > Jul 10 10:38:55 bsd-14 kernel: partner=3D(8000,00-0E-1E-04-2C-F0,0213,800= 0,000E) > Jul 10 10:38:55 bsd-14 kernel: partner.state=3Dd > Jul 10 10:38:55 bsd-14 kernel: maxdelay=3D0 > Jul 10 10:38:55 bsd-14 kernel: ql0: lacpdu receive > Jul 10 10:38:55 bsd-14 kernel: actor=3D(8000,00-0E-1E-04-2C-F0,0213,8000,= 000E) > Jul 10 10:38:55 bsd-14 kernel: actor.state=3D3d > Jul 10 10:38:55 bsd-14 kernel: partner=3D(8000,00-0E-1E-08-05-20,01D3,800= 0,000C) > Jul 10 10:38:55 bsd-14 kernel: partner.state=3D1d > Jul 10 10:38:55 bsd-14 kernel: maxdelay=3D0 > Jul 10 10:38:55 bsd-14 kernel: ql0: old pstate d > Jul 10 10:38:55 bsd-14 kernel: ql0: new pstate 3d > Jul 10 10:38:56 bsd-14 kernel: ql0: enable distributing on aggregator [(8= 000,00-0E-1E-08-05-20,01D3,0000,0000),(8000,00-0E-1E-04-2C-F0,0213,0000,000= 0)], nports 0 -> 1 > Jul 10 10:38:56 bsd-14 kernel: lacp_select_active_aggregator: > Jul 10 10:38:56 bsd-14 kernel: [(8000,00-0E-1E-08-05-20,01D3,0000,0000),(= FFFF,00-00-00-00-00-00,0000,0000,0000)], speed=3D10000000000, nports=3D1 > Jul 10 10:38:56 bsd-14 kernel: [(8000,00-0E-1E-08-05-20,01D3,0000,0000),(= 8000,00-0E-1E-04-2C-F0,0213,0000,0000)], speed=3D10000000000, nports=3D1 > Jul 10 10:38:56 bsd-14 kernel: active aggregator changed > Jul 10 10:38:56 bsd-14 kernel: old [(8000,00-0E-1E-08-05-20,01D3,0000,000= 0),(FFFF,00-00-00-00-00-00,0000,0000,0000)] > Jul 10 10:38:56 bsd-14 kernel: new [(8000,00-0E-1E-08-05-20,01D3,0000,000= 0),(8000,00-0E-1E-04-2C-F0,0213,0000,0000)] > Jul 10 10:38:56 bsd-14 kernel: Set table 0 with 1 ports > Jul 10 10:38:56 bsd-14 kernel: lacp_suppress_distributing > Jul 10 10:38:56 bsd-14 kernel: ql1: marker transmit, port=3D13, sys=3D00:= 0e:1e:08:05:20, id=3D2 > Jul 10 10:38:56 bsd-14 kernel: ql0: marker transmit, port=3D12, sys=3D00:= 0e:1e:08:05:20, id=3D2 > Jul 10 10:38:56 bsd-14 kernel: ql0: mux_state 3 -> 4 > Jul 10 10:38:56 bsd-14 kernel: ql0: marker response, port=3D12, sys=3D00:= 0e:1e:08:05:20, id=3D2 > Jul 10 10:38:59 bsd-14 kernel: lacp_transit_expire > ^C > > > > > System 2 logs : > > Jul 10 02:38:24 bsd-15 kernel: lacp_attach[738] : lacp attached > Jul 10 02:38:24 bsd-15 kernel: lacp_attach[740] : lacp_defined > Jul 10 02:38:24 bsd-15 kernel: lagg0: link state changed to UP > Jul 10 02:38:24 bsd-15 kernel: ql0: media changed 0x0 -> 0x100033, ether = =3D 1, fdx =3D 1, link =3D 1 > Jul 10 02:38:24 bsd-15 kernel: ql0: -> UNSELECTED > Jul 10 02:38:24 bsd-15 kernel: ql1: media changed 0x0 -> 0x100033, ether = =3D 1, fdx =3D 1, link =3D 1 > Jul 10 02:38:24 bsd-15 kernel: ql1: -> UNSELECTED > Jul 10 02:38:24 bsd-15 kernel: lacp_select_tx_port: no active aggregator > Jul 10 02:38:25 bsd-15 kernel: ql1: port lagid=3D[(8000,00-0E-1E-04-2C-F0= ,0213,8000,000F),(0000,00-00-00-00-00-00,0000,0000,0000)] > Jul 10 02:38:25 bsd-15 kernel: ql1: aggregator created > Jul 10 02:38:25 bsd-15 kernel: ql1: aggregator lagid=3D[(8000,00-0E-1E-04= -2C-F0,0213,0000,0000),(0000,00-00-00-00-00-00,0000,0000,0000)] > Jul 10 02:38:25 bsd-15 kernel: ql1: mux_state 0 -> 1 > Jul 10 02:38:25 bsd-15 kernel: ql0: port lagid=3D[(8000,00-0E-1E-04-2C-F0= ,0213,8000,000E),(0000,00-00-00-00-00-00,0000,0000,0000)] > Jul 10 02:38:25 bsd-15 kernel: ql0: aggregator created > Jul 10 02:38:25 bsd-15 kernel: ql0: aggregator lagid=3D[(8000,00-0E-1E-04= -2C-F0,0213,0000,0000),(0000,00-00-00-00-00-00,0000,0000,0000)] > Jul 10 02:38:25 bsd-15 kernel: ql0: mux_state 0 -> 1 > Jul 10 02:38:26 bsd-15 kernel: ql0: lacpdu receive > Jul 10 02:38:26 bsd-15 kernel: actor=3D(8000,00-0E-1E-08-05-20,01D3,8000,= 000C) > Jul 10 02:38:26 bsd-15 kernel: actor.state=3D85 > Jul 10 02:38:26 bsd-15 kernel: partner=3D(0000,00-00-00-00-00-00,0000,000= 0,0000) > Jul 10 02:38:26 bsd-15 kernel: partner.state=3D2 > Jul 10 02:38:26 bsd-15 kernel: maxdelay=3D0 > Jul 10 02:38:26 bsd-15 kernel: ql0: lacp_sm_rx_update_ntt: assert ntt > Jul 10 02:38:26 bsd-15 kernel: ql0: old pstate 2 > Jul 10 02:38:26 bsd-15 kernel: ql0: new pstate 85 > Jul 10 02:38:26 bsd-15 kernel: ql0: partner timeout changed > Jul 10 02:38:26 bsd-15 kernel: ql0: lacpdu transmit > Jul 10 02:38:26 bsd-15 kernel: actor=3D(8000,00-0E-1E-04-2C-F0,0213,8000,= 000E) > Jul 10 02:38:26 bsd-15 kernel: actor.state=3D5 > Jul 10 02:38:26 bsd-15 kernel: partner=3D(8000,00-0E-1E-08-05-20,01D3,800= 0,000C) > Jul 10 02:38:26 bsd-15 kernel: partner.state=3D85 > Jul 10 02:38:26 bsd-15 kernel: maxdelay=3D0 > Jul 10 02:38:26 bsd-15 kernel: ql1: lacpdu transmit > Jul 10 02:38:26 bsd-15 kernel: actor=3D(8000,00-0E-1E-04-2C-F0,0213,8000,= 000F) > Jul 10 02:38:26 bsd-15 kernel: actor.state=3D85 > Jul 10 02:38:26 bsd-15 kernel: partner=3D(0000,00-00-00-00-00-00,0000,000= 0,0000) > Jul 10 02:38:26 bsd-15 kernel: partner.state=3D2 > Jul 10 02:38:26 bsd-15 kernel: maxdelay=3D0 > Jul 10 02:38:26 bsd-15 kernel: ql0: collecting disabled > Jul 10 02:38:26 bsd-15 kernel: lacp_aggregator_delref: lagid=3D[(8000,00-= 0E-1E-04-2C-F0,0213, 0000,0000),(0000,00-00-00-00-00-00,0000,0000,0000)], r= efcnt 1 -> 0 > > Jul 10 02:38:26 bsd-15 kernel: ql0: mux_state 1 -> 0 > Jul 10 02:38:26 bsd-15 kernel: ql0: lacpdu transmit > Jul 10 02:38:26 bsd-15 kernel: actor=3D(8000,00-0E-1E-04-2C-F0,0213,8000,= 000E) > Jul 10 02:38:26 bsd-15 kernel: actor.state=3D5 > Jul 10 02:38:26 bsd-15 kernel: partner=3D(8000,00-0E-1E-08-05-20,01D3,800= 0,000C) > Jul 10 02:38:26 bsd-15 kernel: partner.state=3D85 > Jul 10 02:38:26 bsd-15 kernel: maxdelay=3D0 > Jul 10 02:38:27 bsd-15 kernel: ql0: lacpdu receive > Jul 10 02:38:27 bsd-15 kernel: actor=3D(8000,00-0E-1E-08-05-20,01D3,8000,= 000C) > Jul 10 02:38:27 bsd-15 kernel: actor.state=3D5 > Jul 10 02:38:27 bsd-15 kernel: partner=3D(8000,00-0E-1E-04-2C-F0,0213,800= 0,000E) > Jul 10 02:38:27 bsd-15 kernel: partner.state=3D5 > Jul 10 02:38:27 bsd-15 kernel: maxdelay=3D0 > Jul 10 02:38:27 bsd-15 kernel: ql0: old pstate 85 > Jul 10 02:38:27 bsd-15 kernel: ql0: new pstate 5 > Jul 10 02:38:27 bsd-15 kernel: ql1: lacp_sm_rx_timer: EXPIRED -> DEFAULTE= D > Jul 10 02:38:27 bsd-15 kernel: ql1: partner timeout changed > Jul 10 02:38:27 bsd-15 kernel: ql1: lacp_sm_mux_timer: aggregator [(8000,= 00-0E-1E-04-2C-F0, 0213,0000,0000),(0000,00-00-00-00-00-00,0000,0000,0000)]= , pending 1 -> 0 > Jul 10 02:38:27 bsd-15 kernel: ql1: collecting disabled > Jul 10 02:38:27 bsd-15 kernel: lacp_aggregator_delref: lagid=3D[(8000,00-= 0E-1E-04-2C-F0,0213, 0000,0000),(0000,00-00-00-00-00-00,0000,0000,0000)], r= efcnt 1 -> 0 > > Jul 10 02:38:27 bsd-15 kernel: ql1: mux_state 1 -> 0 > Jul 10 02:38:27 bsd-15 kernel: ql1: lacpdu transmit > Jul 10 02:38:27 bsd-15 kernel: actor=3D(8000,00-0E-1E-04-2C-F0,0213,8000,= 000F) > Jul 10 02:38:27 bsd-15 kernel: actor.state=3D45 > Jul 10 02:38:27 bsd-15 kernel: partner=3D(FFFF,00-00-00-00-00-00,0000,FFF= F,0000) > Jul 10 02:38:27 bsd-15 kernel: partner.state=3D3c > Jul 10 02:38:27 bsd-15 kernel: maxdelay=3D0 > Jul 10 02:38:27 bsd-15 kernel: ql0: port lagid=3D[(8000,00-0E-1E-04-2C-F0= ,0213,8000,000E),(8000,00-0E-1E-08-05-20,01D3,8000,000C)] > Jul 10 02:38:27 bsd-15 kernel: ql0: aggregator created > Jul 10 02:38:27 bsd-15 kernel: ql0: aggregator lagid=3D[(8000,00-0E-1E-04= -2C-F0,0213,0000,0000),(8000,00-0E-1E-08-05-20,01D3,0000,0000)] > Jul 10 02:38:27 bsd-15 kernel: ql0: mux_state 0 -> 1 > Jul 10 02:38:28 bsd-15 kernel: ql1: port lagid=3D[(8000,00-0E-1E-04-2C-F0= ,0213,8000,000F),(FFFF,00-00-00-00-00-00,0000,FFFF,0000)] > Jul 10 02:38:28 bsd-15 kernel: ql1: aggregator created > Jul 10 02:38:28 bsd-15 kernel: ql1: aggregator lagid=3D[(8000,00-0E-1E-04= -2C-F0,0213,0000,0000),(FFFF,00-00-00-00-00-00,0000,0000,0000)] > Jul 10 02:38:28 bsd-15 kernel: ql1: mux_state 0 -> 1 > Jul 10 02:38:29 bsd-15 kernel: ql0: lacp_sm_mux_timer: aggregator [(8000,= 00-0E-1E-04-2C-F0, 0213,0000,0000),(8000,00-0E-1E-08-05-20,01D3,0000,0000)]= , pending 1 -> 0 > Jul 10 02:38:29 bsd-15 kernel: ql0: collecting disabled > Jul 10 02:38:29 bsd-15 kernel: ql0: mux_state 1 -> 2 > Jul 10 02:38:29 bsd-15 kernel: ql0: lacpdu transmit > Jul 10 02:38:29 bsd-15 kernel: actor=3D(8000,00-0E-1E-04-2C-F0,0213,8000,= 000E) > Jul 10 02:38:29 bsd-15 kernel: actor.state=3Dd > Jul 10 02:38:29 bsd-15 kernel: partner=3D(8000,00-0E-1E-08-05-20,01D3,800= 0,000C) > Jul 10 02:38:29 bsd-15 kernel: partner.state=3D5 > Jul 10 02:38:29 bsd-15 kernel: maxdelay=3D0 > Jul 10 02:38:30 bsd-15 kernel: ql0: lacpdu receive > Jul 10 02:38:30 bsd-15 kernel: actor=3D(8000,00-0E-1E-08-05-20,01D3,8000,= 000C) > Jul 10 02:38:30 bsd-15 kernel: actor.state=3D1d > Jul 10 02:38:30 bsd-15 kernel: partner=3D(8000,00-0E-1E-04-2C-F0,0213,800= 0,000E) > Jul 10 02:38:30 bsd-15 kernel: partner.state=3Dd > Jul 10 02:38:30 bsd-15 kernel: maxdelay=3D0 > Jul 10 02:38:30 bsd-15 kernel: ql0: old pstate 5 > Jul 10 02:38:30 bsd-15 kernel: ql0: new pstate 1d > Jul 10 02:38:30 bsd-15 kernel: ql1: lacp_sm_mux_timer: aggregator [(8000,= 00-0E-1E-04-2C-F0, 0213,0000,0000),(FFFF,00-00-00-00-00-00,0000,0000,0000)]= , pending 1 -> 0 > Jul 10 02:38:30 bsd-15 kernel: ql1: collecting disabled > Jul 10 02:38:30 bsd-15 kernel: ql1: mux_state 1 -> 2 > Jul 10 02:38:30 bsd-15 kernel: ql1: collecting enabled > Jul 10 02:38:30 bsd-15 kernel: ql1: mux_state 2 -> 3 > Jul 10 02:38:30 bsd-15 kernel: ql1: enable distributing on aggregator [(8= 000,00-0E-1E-04-2C-F0,0213,0000,0000),(FFFF,00-00-00-00-00-00,0000,0000,000= 0)], nports 0 -> 1 > Jul 10 02:38:30 bsd-15 kernel: lacp_select_active_aggregator: > Jul 10 02:38:30 bsd-15 kernel: [(8000,00-0E-1E-04-2C-F0,0213,0000,0000),(= FFFF,00-00-00-00-00-00,0000,0000,0000)], speed=3D10000000000, nports=3D1 > Jul 10 02:38:30 bsd-15 kernel: active aggregator changed > Jul 10 02:38:30 bsd-15 kernel: old (none) > Jul 10 02:38:30 bsd-15 kernel: new [(8000,00-0E-1E-04-2C-F0,0213,0000,000= 0),(FFFF,00-00-00 00-00-00,0000,0000,0000)] > Jul 10 02:38:30 bsd-15 kernel: Set table 1 with 1 ports > Jul 10 02:38:30 bsd-15 kernel: lacp_suppress_distributing > Jul 10 02:38:30 bsd-15 kernel: ql1: marker transmit, port=3D15, sys=3D00:= 0e:1e:04:2c:f0, id=3D1 > Jul 10 02:38:30 bsd-15 kernel: ql0: marker transmit, port=3D14, sys=3D00:= 0e:1e:04:2c:f0, id=3D1 > Jul 10 02:38:30 bsd-15 kernel: ql1: mux_state 3 -> 4 > Jul 10 02:38:30 bsd-15 kernel: ql1: lacpdu transmit > Jul 10 02:38:30 bsd-15 kernel: ql0: marker response, port=3D14, sys=3D00:= 0e:1e:04:2c:f0, id=3D1 > Jul 10 02:38:30 bsd-15 kernel: actor=3D(8000,00-0E-1E-04-2C-F0,0213,8000,= 000F) > Jul 10 02:38:30 bsd-15 kernel: actor.state=3D7d > Jul 10 02:38:30 bsd-15 kernel: partner=3D(FFFF,00-00-00-00-00-00,0000,FFF= F,0000) > Jul 10 02:38:30 bsd-15 kernel: partner.state=3D3c > Jul 10 02:38:30 bsd-15 kernel: maxdelay=3D0 > Jul 10 02:38:30 bsd-15 kernel: ql0: collecting enabled > Jul 10 02:38:30 bsd-15 kernel: ql0: mux_state 2 -> 3 > Jul 10 02:38:30 bsd-15 kernel: ql0: enable distributing on aggregator [(8= 000,00-0E-1E-04-2C-F0,0213,0000,0000),(8000,00-0E-1E-08-05-20,01D3,0000,000= 0)], nports 0 -> 1 > Jul 10 02:38:30 bsd-15 kernel: lacp_select_active_aggregator: > Jul 10 02:38:30 bsd-15 kernel: [(8000,00-0E-1E-04-2C-F0,0213,0000,0000),(= 8000,00-0E-1E-08-05-20,01D3,0000,0000)], speed=3D10000000000, nports=3D1 > Jul 10 02:38:30 bsd-15 kernel: [(8000,00-0E-1E-04-2C-F0,0213,0000,0000),(= FFFF,00-00-00-00-00-00,0000,0000,0000)], speed=3D10000000000, nports=3D1 > Jul 10 02:38:30 bsd-15 kernel: active aggregator not changed > Jul 10 02:38:30 bsd-15 kernel: new [(8000,00-0E-1E-04-2C-F0,0213,0000,000= 0),(FFFF,00-00-00-00-00-00,0000,0000,0000)] > Jul 10 02:38:30 bsd-15 kernel: ql0: mux_state 3 -> 4 > Jul 10 02:38:30 bsd-15 kernel: ql0: lacpdu transmit > Jul 10 02:38:30 bsd-15 kernel: actor=3D(8000,00-0E-1E-04-2C-F0,0213,8000,= 000E) > Jul 10 02:38:30 bsd-15 kernel: actor.state=3D3d > Jul 10 02:38:30 bsd-15 kernel: partner=3D(8000,00-0E-1E-08-05-20,01D3,800= 0,000C) > Jul 10 02:38:30 bsd-15 kernel: partner.state=3D1d > Jul 10 02:38:30 bsd-15 kernel: maxdelay=3D0 > Jul 10 02:38:33 bsd-15 kernel: lacp_transit_expire > ^C > > Let me know if you need more info. > > Thanks > Adarsh > > > -----Original Message----- > From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd-net@freebsd.org= ] On Behalf Of Adarsh Joshi > Sent: Tuesday, July 10, 2012 10:08 AM > To: Andrew Boyer > Cc: freebsd-net@freebsd.org > Subject: RE: lacp lagg port flags do not show correctly resulting in poor= traffic distribution/performance > > Andrew, > > Thanks for the reply. > > The reason for my suspicion on the portflags is thus (extracted from the = ifconfig output in my previous mail): > > System 1: > Laggport: ql1 flags =3D 18 state =3D 7D > Laggport: ql0 flags =3D 1c state =3D 3D > > System 2: > Laggport: ql1 flags =3D 1c state =3D 7D > Laggport: ql0 flags =3D 18 state =3D 3D > > I should have explained my setup to you before. Here it is. > Both the ql0 interfaces of the 2 systems are connected using a single cab= le and ql1 interfaces of the 2 systems are connected using a single cable. > > System 1 System 2 > ql0 <=3D=3D=3D=3D=3D=3D=3D> ql0 > ql1 <=3D=3D=3D=3D=3D=3D=3D> ql1 > > With this setup, I don't think it is possible for ports ql0 to talk to th= eir partners (each other) and ql1 ports not getting a response from their p= artner and still get the lagg configuration I have posted. > > I thought the portflags are dependent on the LACP state. But I see differ= ent flags for the same LACP state (For the state 7D, ql1 on system 1 shows = flags =3D 18 and ql1 on system 2 shows flags =3D 1c). > > Or is my understanding totally wrong? > > I will send the LACP_DEBUG logs within the hour. > > Thanks > Adarsh > > From: Andrew Boyer [mailto:aboyer@averesystems.com] > Sent: Tuesday, July 10, 2012 5:57 AM > To: Adarsh Joshi > Cc: freebsd-net@freebsd.org > Subject: Re: lacp lagg port flags do not show correctly resulting in poor= traffic distribution/performance > > > On Jul 9, 2012, at 8:38 PM, Adarsh Joshi wrote: > > > Hi, > > I am trying to configure lacp lagg interfaces with 2 systems connected ba= ck to back as follows: > > Ifconfig lagg0 create > Ifconfig lagg0 laggproto lacp laggport ql0 laggport ql1 192.168.100.1 net= mask 255.255.255.0 > > Sometimes, the lag interface comes up correctly but sometimes the laggpor= t flags do not show properly. Instead of 1c= , it shows values of 18. I have seen similar issues reported on various for= ums with no solution. > Looking at the lagg driver code and reading the standard, I thought the l= aggport flags ( defined in if_lagg.h) are based on the LACP_STATE_BITS in f= ile ieee8023ad_lacp.h. But the following ifconfig -v output does not make a= ny sense to me. > > My concern is that when all the interfaces show flags as 1c, the traffic = is distributed across both the interfaces uniformly and I get aggregated th= roughput. If not, the traffic flows only on 1 interface. > > Is this a bug? How do I solve this? Or am I doing something wrong? > > I am using Free-BSD 9.0 release. > > System 1: > # ifconfig -v lagg0 > lag id: [(8000,00-0E-1E-08-05-20,0213,0000,0000), > (8000,00-0E-1E-04-2C-F0,0213,0000,0000)] > laggport: ql1 flags=3D18 state=3D7D > [(8000,00-0E-1E-08-05-20,0213,8000,000F), > (FFFF,00-00-00-00-00-00,0000,FFFF,0000)] > laggport: ql0 flags=3D1c state=3D3D > [(8000,00-0E-1E-08-05-20,0213,8000,000E), > (8000,00-0E-1E-04-2C-F0,0213,8000,000E)] > > System 2: > > # ifconfig -v lagg0 > lag id: [(8000,00-0E-1E-04-2C-F0,0213,0000,0000), > (FFFF,00-00-00-00-00-00,0000,0000,0000)] > laggport: ql1 flags=3D1c state=3D7D > [(8000,00-0E-1E-04-2C-F0,0213,8000,000F), > (FFFF,00-00-00-00-00-00,0000,FFFF,0000)] > laggport: ql0 flags=3D18 state=3D3D > [(8000,00-0E-1E-04-2C-F0,0213,8000,000E), > (8000,00-0E-1E-08-05-20,0213,8000,000E)] > > > thanks > Adarsh > > I don't think you have a port flags problem per se; the flags are correct= ly displaying the state of the lagg. Your problem is that your systems are= n't negotiating the correct lagg configuration. Each tuple after the laggp= ort represents the [(actor state),(partner state)]. Ports ql0 have been ab= le to talk to their partners (each other). Neither ql1 port has seen a res= ponse from a partner, though. > > You could try restarting the state machine on one box with 'ifconfig lagg= 0 laggproto lacp'. To see the negotiation you'll need to rebuild your kern= el with '#define LACP_DEBUG 1' added to the top of sys/net/ieee802.3ad_lacp= .c. Or upgrade to a newer stable snapshot that has the net.lacp_debug sysc= tl and turn it on. > > Or just turn off LACP. What does it get you in this configuration? > > Hope this helps, > Andrew > > -------------------------------------------------- > Andrew Boyer aboyer@averesystems.com > > > > > > ________________________________ > This message and any attached documents contain information from QLogic C= orporation or its wholly-owned subsidiaries that may be confidential. If yo= u are not the intended recipient, you may not read, copy, distribute, or us= e this information. If you have received this transmission in error, please= notify the sender immediately by reply e-mail and then delete this message= . > _______________________________________________ > 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" > > > This message and any attached documents contain information from QLogic C= orporation or its wholly-owned subsidiaries that may be confidential. If yo= u are not the intended recipient, you may not read, copy, distribute, or us= e this information. If you have received this transmission in error, please= notify the sender immediately by reply e-mail and then delete this message= . > -------------------------------------------------- Andrew Boyer aboyer@averesystems.com This message and any attached documents contain information from QLogic Cor= poration or its wholly-owned subsidiaries that may be confidential. If you = are not the intended recipient, you may not read, copy, distribute, or use = this information. If you have received this transmission in error, please n= otify the sender immediately by reply e-mail and then delete this message. From owner-freebsd-net@FreeBSD.ORG Fri Jul 27 22:14:51 2012 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 85D8E106566C for ; Fri, 27 Jul 2012 22:14:51 +0000 (UTC) (envelope-from adarsh.joshi@qlogic.com) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe010.messaging.microsoft.com [216.32.180.30]) by mx1.freebsd.org (Postfix) with ESMTP id 23AA88FC16 for ; Fri, 27 Jul 2012 22:14:51 +0000 (UTC) Received: from mail246-va3-R.bigfish.com (10.7.14.251) by VA3EHSOBE003.bigfish.com (10.7.40.23) with Microsoft SMTP Server id 14.1.225.23; Fri, 27 Jul 2012 21:59:42 +0000 Received: from mail246-va3 (localhost [127.0.0.1]) by mail246-va3-R.bigfish.com (Postfix) with ESMTP id 253CC480400 for ; Fri, 27 Jul 2012 21:59:42 +0000 (UTC) X-Forefront-Antispam-Report: CIP:198.70.193.64; KIP:(null); UIP:(null); IPV:NLI; H:avexcashub1.qlogic.com; RD:avexcashub2.qlogic.com; EFVD:NLI X-SpamScore: 4 X-BigFish: VPS4(z33fclzc85fhzz1202hzz8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah) Received-SPF: pass (mail246-va3: domain of qlogic.com designates 198.70.193.64 as permitted sender) client-ip=198.70.193.64; envelope-from=adarsh.joshi@qlogic.com; helo=avexcashub1.qlogic.com ; 1.qlogic.com ; Received: from mail246-va3 (localhost.localdomain [127.0.0.1]) by mail246-va3 (MessageSwitch) id 1343426380542534_6937; Fri, 27 Jul 2012 21:59:40 +0000 (UTC) Received: from VA3EHSMHS006.bigfish.com (unknown [10.7.14.240]) by mail246-va3.bigfish.com (Postfix) with ESMTP id 7906C780045 for ; Fri, 27 Jul 2012 21:59:40 +0000 (UTC) Received: from avexcashub1.qlogic.com (198.70.193.64) by VA3EHSMHS006.bigfish.com (10.7.99.16) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 27 Jul 2012 21:59:40 +0000 Received: from avexmb1.qlogic.org ([fe80::9545:3a4f:c131:467d]) by avexcashub2.qlogic.org ([::1]) with mapi; Fri, 27 Jul 2012 14:59:38 -0700 From: Adarsh Joshi To: "freebsd-net@freebsd.org" Date: Fri, 27 Jul 2012 14:59:37 -0700 Thread-Topic: check pending callouts Thread-Index: Ac1sQuxBIQkLDkPdQtmui6aPB8k8YA== Message-ID: <5E4F49720D0BAD499EE1F01232234BA87743A5E910@AVEXMB1.qlogic.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-OriginatorOrg: qlogic.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: check pending callouts 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, 27 Jul 2012 22:14:51 -0000 Hi, Is there a way to check pending callouts? I mean, like a command or utility, or do I have to panic the kernel and che= ck it at the debugger prompt? regards Adarsh ________________________________ This message and any attached documents contain information from QLogic Cor= poration or its wholly-owned subsidiaries that may be confidential. If you = are not the intended recipient, you may not read, copy, distribute, or use = this information. If you have received this transmission in error, please n= otify the sender immediately by reply e-mail and then delete this message. From owner-freebsd-net@FreeBSD.ORG Sat Jul 28 06:15:58 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4D5A2106564A for ; Sat, 28 Jul 2012 06:15:58 +0000 (UTC) (envelope-from jhellenthal@dataix.net) Received: from mail-gg0-f182.google.com (mail-gg0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id E5D1C8FC0C for ; Sat, 28 Jul 2012 06:15:57 +0000 (UTC) Received: by ggnm2 with SMTP id m2so4520775ggn.13 for ; Fri, 27 Jul 2012 23:15:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; bh=yt8I34lVTjK+y7HYrh7G0cVUqzDiFB2/ou0sJOkLZpk=; b=LTOGnJeFIVrfTtuSyYnvuNcaSCyhuBH2BkvbzmLUJ0oXBq0zLQcquEsblnX0WSpp8B r0t4u6uiDfl18oFd8yiGS6K4cBa5fLQYG7cMhozybD1896ytnAWxj6rSiN5fn55BWWZq xU9Zot03q6AUx4SQ+DnW5IkF5Rqi7L6ylajUA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-gm-message-state; bh=yt8I34lVTjK+y7HYrh7G0cVUqzDiFB2/ou0sJOkLZpk=; b=ZdzJ492x63kDglwkVTOLYZZ1smXMqMBtOwUtMTILRNwShPBS6AlmTEJ72cc6V6QMqT WGrMM3EpiS5C5DAXnhEuiDzQbXd4T/EfeRREBVqAu2v9QokELPi0kKD2t4zW6TKuBrSr sPyqgFc26/i8JNhsdoG2CLgJDrKyMB7RnjZtawN0lSHXnYvxkrLyd2qdbAE93rIHYyEB GGqySygx60XMsTVgeM2TttMOc17MJVuLPcqpoqgPaZDuRBNWEQXAd41+XK6ORwhukma/ IKP5cNiljN4yMpcrM3IvI4sDgC1U7cPfz+NjLMQgkaYDG2UpgdI4zSiV7/0J4dI10z6e 2OPw== Received: by 10.42.61.134 with SMTP id u6mr3138435ich.11.1343456156904; Fri, 27 Jul 2012 23:15:56 -0700 (PDT) Received: from DataIX.net (adsl-99-109-126-173.dsl.klmzmi.sbcglobal.net. [99.109.126.173]) by mx.google.com with ESMTPS id fe7sm2244575igc.14.2012.07.27.23.15.51 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 27 Jul 2012 23:15:56 -0700 (PDT) Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.5/8.14.5) with ESMTP id q6S6FJUr005222 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 28 Jul 2012 02:15:20 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Received: (from jh@localhost) by DataIX.net (8.14.5/8.14.5/Submit) id q6S6FBGQ005069; Sat, 28 Jul 2012 02:15:11 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Date: Sat, 28 Jul 2012 02:15:11 -0400 From: Jason Hellenthal To: Adarsh Joshi Message-ID: <20120728061511.GA3452@DataIX.net> References: <5E4F49720D0BAD499EE1F01232234BA87743A5E910@AVEXMB1.qlogic.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2fHTh5uZTiUOsy+g" Content-Disposition: inline In-Reply-To: <5E4F49720D0BAD499EE1F01232234BA87743A5E910@AVEXMB1.qlogic.org> X-Gm-Message-State: ALoCoQmxrfg/8ZVq4Un8oixAn5scUdYQmVZPc0a8u2vpaykLpxcMUf8slnfOHsqmGxiGA11vthBA Cc: "freebsd-net@freebsd.org" Subject: Re: check pending callouts 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, 28 Jul 2012 06:15:58 -0000 --2fHTh5uZTiUOsy+g Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 27, 2012 at 02:59:37PM -0700, Adarsh Joshi wrote: > Hi, >=20 > Is there a way to check pending callouts? > I mean, like a command or utility, or do I have to panic the kernel and c= heck it at the debugger prompt? >=20 You should be able to dtrace that out and uncover whats going on with a little intellect. The D language itself might take a little learning but it would be worth your while to pick it up now instead of later. --=20 - (2^(N-1)) JJH48-ARIN --2fHTh5uZTiUOsy+g Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJQE4NuAAoJEBSh2Dr1DU7WZXwH/0OOEqgGWrj5j6Jz8e3eExOu EwG5IRLpKs7SqGbDdc5LGEnqGiA/gbEj4Ot2a9uWkLJ2kln8beMzlNUXkMA40bso MLq+6aunfOf2+L1rLG89domahqlITo+04kuuP9EsLjWYPa+PmU2z1KMotE3+HBOp gUjiG3UdgBFsW4kCSqtve1A7N7f3oiGgd4GGeZvDZrTSt1ehxfwaRMC9vFB8s8h8 00yK2ffoIChbIkb0F6fqNlCOwGQTUdkQMJODGsC8TH7d+IPOESvkhLii/HjRCid9 GcWtP0RSbInO55StNNgf8C5tWJaJWoFE2EhPjWYuA9AUY4GhhkzvpALoTLKf7Fk= =zXRw -----END PGP SIGNATURE----- --2fHTh5uZTiUOsy+g-- From owner-freebsd-net@FreeBSD.ORG Sat Jul 28 18:44:38 2012 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 C70B31065670 for ; Sat, 28 Jul 2012 18:44:38 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7EC7A8FC08 for ; Sat, 28 Jul 2012 18:44:38 +0000 (UTC) Received: by vcbgb22 with SMTP id gb22so4376708vcb.13 for ; Sat, 28 Jul 2012 11:44:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zkORXZ5ywTFj+S+d7plehBQcLGP0ciwUF+wwnzTKRWM=; b=gI4qDd6V6vreDbzovwIfRqfgmoAbGKAvJzIrfP5FzMucoMk4uvf5OI6DwHiuY4vvEg 17Q7oIglOChYIrFPpQFo6e5JTuAkshAiEMRBtuF3O4N8Exr3CJGmq2sFD/BcNNuZA+JW 7Rf44cSPhko9csoHuQwJe9kZ7xUrnOEcppIeIS0cgjBNCJSPQpTk4IoBOcxDRfBRugO6 L2SOCdrE986iKSVZNO7KsEQdKtLs4Unq4VqYozg8lHtGPzefMjpoCKVDjLGZnQZ0VmI3 qiLeeFLiH96OCWyrHZ7hVWju3/Iss1yMGFQmWn70AlCVUNDPBsy5PIIROAMXnkCvzdVE Bukw== MIME-Version: 1.0 Received: by 10.220.152.138 with SMTP id g10mr6275618vcw.14.1343501072621; Sat, 28 Jul 2012 11:44:32 -0700 (PDT) Received: by 10.58.12.202 with HTTP; Sat, 28 Jul 2012 11:44:32 -0700 (PDT) In-Reply-To: <20120728061511.GA3452@DataIX.net> References: <5E4F49720D0BAD499EE1F01232234BA87743A5E910@AVEXMB1.qlogic.org> <20120728061511.GA3452@DataIX.net> Date: Sat, 28 Jul 2012 14:44:32 -0400 Message-ID: From: Ryan Stone To: Jason Hellenthal Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-net@freebsd.org" , Adarsh Joshi Subject: Re: check pending callouts 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, 28 Jul 2012 18:44:38 -0000 On Sat, Jul 28, 2012 at 2:15 AM, Jason Hellenthal wrote: > You should be able to dtrace that out and uncover whats going on with a > little intellect. > > The D language itself might take a little learning but it would be worth > your while to pick it up now instead of later. Actually, D isn't a great language for this type of thing because it lacks the able to loop. At dtrace.conf in April they discussed adding restricted iteration of some kind, but it sounds like it's a long way out right now. It is possible to attach kgdb to /dev/mem to do live analysis of a running kernel. Of course with callouts this may not work out so well because the callout wheel will be constantly changing out from under kgdb. From owner-freebsd-net@FreeBSD.ORG Sat Jul 28 22:50:52 2012 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 6C1C6106564A; Sat, 28 Jul 2012 22:50:52 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mx1.sbone.de (bird.sbone.de [46.4.1.90]) by mx1.freebsd.org (Postfix) with ESMTP id E5AFA8FC14; Sat, 28 Jul 2012 22:50:51 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id EEC7925D387B; Sat, 28 Jul 2012 22:50:50 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 1CA21BE8553; Sat, 28 Jul 2012 22:50:50 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id ElrPKQDRKf7h; Sat, 28 Jul 2012 22:50:48 +0000 (UTC) Received: from nv.sbone.de (nv.sbone.de [IPv6:fde9:577b:c1a9:31::2013:138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 6EFA9BE8552; Sat, 28 Jul 2012 22:50:48 +0000 (UTC) Date: Sat, 28 Jul 2012 22:50:47 +0000 (UTC) From: "Bjoern A. Zeeb" To: Doug Barton In-Reply-To: <50117FB2.1060306@FreeBSD.org> Message-ID: References: <50117DB0.7010909@mh-sec.de> <50117FB2.1060306@FreeBSD.org> X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1307323017-1343515848=:4474" Cc: freebsd-net@FreeBSD.org Subject: Re: Fwd: Re: [ipv6hackers] funny FreeBSD bug 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, 28 Jul 2012 22:50:52 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1307323017-1343515848=:4474 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT On Thu, 26 Jul 2012, Doug Barton wrote: > FYI, this conversation is happening in the list below. I have no opinion > regarding whether it is a bug or not, but I thought folks here might be > interested. > You can point the people at both the RFC and the SA we have issues a couple of years ago and why it's always 4 or 8 bytes below the minimal MTU. It's all good. > > > -------- Original Message -------- > Subject: Re: [ipv6hackers] funny FreeBSD bug > Date: Thu, 26 Jul 2012 19:26:08 +0200 > From: Marc Heuse > Reply-To: IPv6 Hackers Mailing List > To: IPv6 Hackers Mailing List , > Simon Perreault > > Hi Simon, > > Am 26.07.2012 17:47, schrieb Simon Perreault: >> Le 2012-07-26 08:35, Marc Heuse a écrit : >>> I found a funny bug in freebsd (9.0 with all updates): >>> if you send an ICMP toobig message to it with a too low MTU size, >>> FreeBSD will prepend any packet data with an one-shot fragment (or >>> atomic fragment as Fernando calls it). >> >> Why do you think it's a bug? > > first it servs no use to add the fragmentation header if the packet is > not fragmented. second I have not seen this behaviour in other OS, > however I havent looked for it though. > >> Seems like normal IPv6 behaviour to me. It's in the RFC... > I cant remember having seen this in any rfc - do you have a pointer? > > Greets, > Marc > > -- > Marc Heuse > www.mh-sec.de > > PGP: FEDD 5B50 C087 F8DF 5CB9 876F 7FDD E533 BF4F 891A > _______________________________________________ > Ipv6hackers mailing list > Ipv6hackers@lists.si6networks.com > http://lists.si6networks.com/listinfo/ipv6hackers > > > _______________________________________________ > 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" > -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. --0-1307323017-1343515848=:4474-- From owner-freebsd-net@FreeBSD.ORG Sat Jul 28 23:15:19 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 33907106566B; Sat, 28 Jul 2012 23:15:19 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from opti.dougb.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 9663C14ED52; Sat, 28 Jul 2012 23:15:18 +0000 (UTC) Message-ID: <50147286.4060509@FreeBSD.org> Date: Sat, 28 Jul 2012 16:15:18 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:13.0) Gecko/20120624 Thunderbird/13.0.1 MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <50117DB0.7010909@mh-sec.de> <50117FB2.1060306@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org Subject: Re: Fwd: Re: [ipv6hackers] funny FreeBSD bug 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, 28 Jul 2012 23:15:19 -0000 On 07/28/2012 15:50, Bjoern A. Zeeb wrote: > You can point the people ... I'm not pointing anyone at anything. I raised the issue here in case anyone here is interested in following up. Fernando already did. Doug -- Change is hard.