From owner-freebsd-net@FreeBSD.ORG Sun Jan 23 07:40:09 2011 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 DA8C3106564A for ; Sun, 23 Jan 2011 07:40:09 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id AF4AB8FC0A for ; Sun, 23 Jan 2011 07:40:09 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p0N7e9rw074644 for ; Sun, 23 Jan 2011 07:40:09 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p0N7e98A074643; Sun, 23 Jan 2011 07:40:09 GMT (envelope-from gnats) Date: Sun, 23 Jan 2011 07:40:09 GMT Message-Id: <201101230740.p0N7e98A074643@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: PseudoCylon Cc: Subject: Re: kern/153938: [run] [panic] [patch] Workaround for use-after-free panic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: PseudoCylon List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jan 2011 07:40:09 -0000 The following reply was made to PR kern/153938; it has been noted by GNATS. From: PseudoCylon To: bug-followup@freebsd.org, Juergen Lock Cc: Juergen Lock Subject: Re: kern/153938: [run] [panic] [patch] Workaround for use-after-free panic Date: Sat, 22 Jan 2011 23:35:14 -0800 (PST) ----- Original Message ---- > From: Juergen Lock > To: PseudoCylon > Cc: bug-followup@freebsd.org; Juergen Lock > Sent: Fri, January 21, 2011 11:21:20 AM > Subject: Re: kern/153938: [run] [panic] [patch] Workaround for use-after-free >panic > > It's possible this was triggered by the first DPRINTFN() in > run_node_cleanup() (that I turned into a device_printf() and meanwhile > have disabled, maybe it caused a taskswitch) Your bt says no. > #5 0xffffffff8117839b in run_node_cleanup (ni=0xffffff8000f83000) > at >/data2v/home/nox/src-r81/src/sys/modules/usb/run/../../../dev/usb/wlan/if_run.c:1719 > > 1719 RUN_LOCK(sc); > (kgdb) l run_node_cleanup() was called with node lock held. Happens all the time. > - but in any case I'd > say this is not safe i.e. needs to be fixed. :) > Yes. Here is fix. This one shall work. http://gitorious.org/run/run/trees/fifo_fix/dev/usb/wlan AK From owner-freebsd-net@FreeBSD.ORG Sun Jan 23 15:06:31 2011 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 13C17106564A for ; Sun, 23 Jan 2011 15:06:31 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [62.231.161.221]) by mx1.freebsd.org (Postfix) with ESMTP id 5B3788FC0C for ; Sun, 23 Jan 2011 15:06:29 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.4/8.14.4) with ESMTP id p0NF6RQa069316; Sun, 23 Jan 2011 21:06:27 +0600 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4D3C43EE.8060307@rdtc.ru> Date: Sun, 23 Jan 2011 21:06:22 +0600 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: "net@freebsd.org" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org Subject: Querying bsnmpd through /var/run/snmpd.sock 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, 23 Jan 2011 15:06:31 -0000 Hi! bsnmpd running with mibII module opens local socket /var/run/snmpd.sock mentioned in snmp_mibII(3) manual page: The mibII module opens a socket that is used to execute all network related ioctl(2) functions. This socket is globally available under the name mib_netsock. How do I use the socket? I hope to be able to call mib_find_if_sys() function from another process using the socket. Is there a documentation for this? Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Sun Jan 23 15:19:00 2011 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 D4E861065672 for ; Sun, 23 Jan 2011 15:19:00 +0000 (UTC) (envelope-from e0326715@student.tuwien.ac.at) Received: from mr.tuwien.ac.at (mr1-n.kom.tuwien.ac.at [128.130.2.109]) by mx1.freebsd.org (Postfix) with ESMTP id 61BFB8FC1B for ; Sun, 23 Jan 2011 15:18:59 +0000 (UTC) Received: from webmail1.zserv.tuwien.ac.at (webmail1.zserv.tuwien.ac.at [128.130.35.11]) by mr.tuwien.ac.at (8.13.7/8.13.7) with ESMTP id p0NFIuK4012848; Sun, 23 Jan 2011 16:18:56 +0100 (MET) Received: from webmail1.zserv.tuwien.ac.at (localhost.localdomain [127.0.0.1]) by webmail1.zserv.tuwien.ac.at (8.13.8/8.13.8) with ESMTP id p0NFIuWO003728; Sun, 23 Jan 2011 16:18:56 +0100 Received: (from apache@localhost) by webmail1.zserv.tuwien.ac.at (8.13.8/8.13.8/Submit) id p0NFIu4I003725; Sun, 23 Jan 2011 16:18:56 +0100 X-Authentication-Warning: webmail1.zserv.tuwien.ac.at: apache set sender to e0326715@student.tuwien.ac.at using -f Received: from 194.24.158.3 ([194.24.158.3]) by webmail.tuwien.ac.at (Horde Framework) with HTTP; Sun, 23 Jan 2011 16:18:55 +0100 Message-ID: <20110123161855.91975nun1ymhwgyn@webmail.tuwien.ac.at> Date: Sun, 23 Jan 2011 16:18:55 +0100 From: Schoch Christian To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.9) X-Virus-Scanned: by amavisd-new Cc: tuexen@fh-muenster.de Subject: connect with SOCK_SEQPACKET 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, 23 Jan 2011 15:19:00 -0000 Hi, While porting a SCTP test tool, I figured out, that connect with SOCK_SEQPACKET (SCTP 1-to-many style socket) is always returning 0, regardless if the connection could be established or not. The problem is that this result is responsible for client or server mode of the tools. If this is not a bug, how can I manage this issue ? Regards, Christian From owner-freebsd-net@FreeBSD.ORG Sun Jan 23 15:22:01 2011 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 7974A106564A; Sun, 23 Jan 2011 15:22:01 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id EF0128FC12; Sun, 23 Jan 2011 15:22:00 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a] (saphire3.sentex.ca [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a]) by smarthost1.sentex.ca (8.14.4/8.14.4) with ESMTP id p0NFLwZX036972 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 23 Jan 2011 10:21:59 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <4D3C4795.40205@sentex.net> Date: Sun, 23 Jan 2011 10:21:57 -0500 From: Mike Tancsa User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Jan Koum References: <1290533941.3173.50.camel@home-yahoo> <4CEC0548.1080801@sentex.net> <4D2C636B.5040003@sentex.net> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on IPv6:2607:f3e0:0:1::12 Cc: "freebsd-net@freebsd.org" , Sean Bruno , "freebsd-hardware@freebsd.org" , Jack Vogel , Ivan Voras Subject: Re: em driver, 82574L chip, and possibly ASPM 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, 23 Jan 2011 15:22:01 -0000 On 1/21/2011 4:21 AM, Jan Koum wrote: > > > Dear Mike and Jack, > > sadly the problem is not gone for us either. here is what we know so far: Same here. There was a new BIOS from Intel for our motherboard (INTEL S3420GPX), but had another hang last night. Debug below. I will try the newer driver Monday. One other thing I noticed is that when the nic is in its hung state, the WOL option is gone ? e.g em1: flags=8843 metric 0 mtu 1500 options=19b ether 00:15:17:ed:68:a4 vs em1: flags=8843 metric 0 mtu 1500 options=219b ether 00:15:17:ed:68:a4 Interface is RUNNING and INACTIVE em1: hw tdh = 75, hw tdt = 75 em1: hw rdh = 771, hw rdt = 771 em1: Tx Queue Status = 0 em1: TX descriptors avail = 1024 em1: Tx Descriptors avail failure = 0 em1: RX discarded packets = 0 em1: RX Next to Check = 771 em1: RX Next to Refresh = 772 em1: link state changed to DOWN em1: link state changed to UP dev.em.1.%desc: Intel(R) PRO/1000 Network Connection 7.1.8 dev.em.1.%driver: em dev.em.1.%location: slot=0 function=0 handle=\_SB_.PCI0.PEX4.HART dev.em.1.%pnpinfo: vendor=0x8086 device=0x10d3 subvendor=0x8086 subdevice=0x34ec class=0x020000 dev.em.1.%parent: pci10 dev.em.1.nvm: -1 dev.em.1.debug: -1 dev.em.1.rx_int_delay: 0 dev.em.1.tx_int_delay: 66 dev.em.1.rx_abs_int_delay: 66 dev.em.1.tx_abs_int_delay: 66 dev.em.1.rx_processing_limit: 100 dev.em.1.flow_control: 3 dev.em.1.link_irq: 563 dev.em.1.mbuf_alloc_fail: 0 dev.em.1.cluster_alloc_fail: 0 dev.em.1.dropped: 0 dev.em.1.tx_dma_fail: 0 dev.em.1.rx_overruns: 0 dev.em.1.watchdog_timeouts: 0 dev.em.1.device_control: 1209008712 dev.em.1.rx_control: 67141634 dev.em.1.fc_high_water: 18432 dev.em.1.fc_low_water: 16932 dev.em.1.queue0.txd_head: 68 dev.em.1.queue0.txd_tail: 68 dev.em.1.queue0.tx_irq: 6378625 dev.em.1.queue0.no_desc_avail: 0 dev.em.1.queue0.rxd_head: 771 dev.em.1.queue0.rxd_tail: 771 dev.em.1.queue0.rx_irq: 6987244 dev.em.1.mac_stats.excess_coll: 0 dev.em.1.mac_stats.single_coll: 0 dev.em.1.mac_stats.multiple_coll: 0 dev.em.1.mac_stats.late_coll: 0 dev.em.1.mac_stats.collision_count: 0 dev.em.1.mac_stats.symbol_errors: 0 dev.em.1.mac_stats.sequence_errors: 0 dev.em.1.mac_stats.defer_count: 0 dev.em.1.mac_stats.missed_packets: 625 dev.em.1.mac_stats.recv_no_buff: 16 dev.em.1.mac_stats.recv_undersize: 0 dev.em.1.mac_stats.recv_fragmented: 0 dev.em.1.mac_stats.recv_oversize: 0 dev.em.1.mac_stats.recv_jabber: 0 dev.em.1.mac_stats.recv_errs: 0 dev.em.1.mac_stats.crc_errs: 0 dev.em.1.mac_stats.alignment_errs: 0 dev.em.1.mac_stats.coll_ext_errs: 0 dev.em.1.mac_stats.xon_recvd: 0 dev.em.1.mac_stats.xon_txd: 0 dev.em.1.mac_stats.xoff_recvd: 0 dev.em.1.mac_stats.xoff_txd: 0 dev.em.1.mac_stats.total_pkts_recvd: 28035460 dev.em.1.mac_stats.good_pkts_recvd: 28034835 dev.em.1.mac_stats.bcast_pkts_recvd: 2649 dev.em.1.mac_stats.mcast_pkts_recvd: 892 dev.em.1.mac_stats.rx_frames_64: 1443 dev.em.1.mac_stats.rx_frames_65_127: 398677 dev.em.1.mac_stats.rx_frames_128_255: 154336 dev.em.1.mac_stats.rx_frames_256_511: 473952 dev.em.1.mac_stats.rx_frames_512_1023: 199839 dev.em.1.mac_stats.rx_frames_1024_1522: 26806588 dev.em.1.mac_stats.good_octets_recvd: 40546236160 dev.em.1.mac_stats.good_octets_txd: 1625971127 dev.em.1.mac_stats.total_pkts_txd: 18447279 dev.em.1.mac_stats.good_pkts_txd: 18447279 dev.em.1.mac_stats.bcast_pkts_txd: 194 dev.em.1.mac_stats.mcast_pkts_txd: 6 dev.em.1.mac_stats.tx_frames_64: 352 dev.em.1.mac_stats.tx_frames_65_127: 16626040 dev.em.1.mac_stats.tx_frames_128_255: 1790624 dev.em.1.mac_stats.tx_frames_256_511: 876 dev.em.1.mac_stats.tx_frames_512_1023: 902 dev.em.1.mac_stats.tx_frames_1024_1522: 28485 dev.em.1.mac_stats.tso_txd: 2542 dev.em.1.mac_stats.tso_ctx_fail: 0 dev.em.1.interrupts.asserts: 222 dev.em.1.interrupts.rx_pkt_timer: 0 dev.em.1.interrupts.rx_abs_timer: 0 dev.em.1.interrupts.tx_pkt_timer: 0 dev.em.1.interrupts.tx_abs_timer: 0 dev.em.1.interrupts.tx_queue_empty: 0 dev.em.1.interrupts.tx_queue_min_thresh: 0 dev.em.1.interrupts.rx_desc_min_thresh: 0 dev.em.1.interrupts.rx_overrun: 0 From owner-freebsd-net@FreeBSD.ORG Sun Jan 23 15:36:40 2011 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 9ACDC1065670 for ; Sun, 23 Jan 2011 15:36:40 +0000 (UTC) (envelope-from tuexen@fh-muenster.de) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by mx1.freebsd.org (Postfix) with ESMTP id 06E558FC08 for ; Sun, 23 Jan 2011 15:36:39 +0000 (UTC) Received: from [192.168.1.113] (p508F9A39.dip.t-dialin.net [80.143.154.57]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id B22061C0C0BCA; Sun, 23 Jan 2011 16:36:37 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Michael Tuexen In-Reply-To: <20110123161855.91975nun1ymhwgyn@webmail.tuwien.ac.at> Date: Sun, 23 Jan 2011 16:36:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <900DC43F-8CD2-4EFB-B63D-63B541EF5119@fh-muenster.de> References: <20110123161855.91975nun1ymhwgyn@webmail.tuwien.ac.at> To: Schoch Christian X-Mailer: Apple Mail (2.1082) Cc: freebsd-net@freebsd.org Subject: Re: connect with SOCK_SEQPACKET 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, 23 Jan 2011 15:36:40 -0000 On Jan 23, 2011, at 4:18 PM, Schoch Christian wrote: > Hi, >=20 > While porting a SCTP test tool, I figured out, that connect with = SOCK_SEQPACKET (SCTP 1-to-many style socket) is always returning 0, = regardless if the connection could be established or not. >=20 > The problem is that this result is responsible for client or server = mode of the tools. >=20 > If this is not a bug, how can I manage this issue ? Hi Christian, you need to subscribe to notifications. You will either get a SCTP_COMM_UP notification or a SCTP_CANT_STR_ASSOC notification. Best regards Michael >=20 > Regards, > Christian >=20 >=20 From owner-freebsd-net@FreeBSD.ORG Sun Jan 23 16:15:07 2011 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 E2E5D1065670 for ; Sun, 23 Jan 2011 16:15:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id 710C18FC13 for ; Sun, 23 Jan 2011 16:15:07 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 785B041C650 for ; Sun, 23 Jan 2011 17:15:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id Itz9zrSVJB11 for ; Sun, 23 Jan 2011 17:15:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id B619641C64A; Sun, 23 Jan 2011 17:15:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 91EAB4448F3 for ; Sun, 23 Jan 2011 16:13:48 +0000 (UTC) Date: Sun, 23 Jan 2011 16:13:48 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: freebsd-net@freebsd.org Message-ID: <20110123161137.A3489@maildrop.int.zabbadoz.net> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: NAT-T/UDPENCAP patch from stable/7 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jan 2011 16:15:08 -0000 Hi, here is a version of the NAT-T/UDPENCAP patch as in 8 and 9 for today's stable/7 for anyone who might want/need it. I would expect it will equally apply to 7.4-RELEASE once that happened. http://people.freebsd.org/~bz/20110123-01-stable7-natt.diff You will need to figure out the right version of ipsec-tools or other IKE clients yourself though. /bz -- Bjoern A. Zeeb You have to have visions! Going to jail sucks -- All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html From owner-freebsd-net@FreeBSD.ORG Sun Jan 23 19:44:53 2011 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 DAD921065673 for ; Sun, 23 Jan 2011 19:44:53 +0000 (UTC) (envelope-from prvs=100478bcf4=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 75E3C8FC18 for ; Sun, 23 Jan 2011 19:44:53 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Sun, 23 Jan 2011 19:33:57 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Sun, 23 Jan 2011 19:33:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50012042776.msg for ; Sun, 23 Jan 2011 19:33:57 +0000 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=100478bcf4=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-net@freebsd.org Message-ID: <3037495B413A48AE9BCDF7C567ED2A8D@multiplay.co.uk> From: "Steven Hartland" To: Date: Sun, 23 Jan 2011 19:34:12 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Subject: getpeername returning ENOTCONN for a connected socket 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, 23 Jan 2011 19:44:53 -0000 I've been trying to debug an issue where a call to getpeername on a connected tcp socket returns ENOTCONN with no prior errors being reported by previous socket calls. At first I thought this was perl / perl module bug but I've now reproduced the behaviour with a small native c client. The flow is:- 0. socket 1. connect 2. getpeername 3. send 4. recv <- 14 bytes 5. sleep(1) 6. getpeername 7. send 8. recv <- 0 bytes 9. getpeername 10. send 11. recv <- 0 bytes 12. getpeername <- error ENOTCONN Now given no previous errors from either connect, send or recv if the connection has been terminated by the other end, which tcpdump shows its has (RST), I would expect to get ECONNRESET from getpeername and not ENOTCONN. The only case I would expect ENOTCONN is if either no connect call had been made or if it was unsuccessful. Am I missing something here, is ENOTCONN and expected result from a previously connected socket with no other indication of error? Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-net@FreeBSD.ORG Sun Jan 23 20:09:48 2011 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 815FE1065675 for ; Sun, 23 Jan 2011 20:09:48 +0000 (UTC) (envelope-from prvs=100478bcf4=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 1963B8FC18 for ; Sun, 23 Jan 2011 20:09:47 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Sun, 23 Jan 2011 20:09:32 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Sun, 23 Jan 2011 20:09:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50012042848.msg for ; Sun, 23 Jan 2011 20:09:32 +0000 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=100478bcf4=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-net@freebsd.org Message-ID: From: "Steven Hartland" To: References: <3037495B413A48AE9BCDF7C567ED2A8D@multiplay.co.uk> Date: Sun, 23 Jan 2011 20:09:47 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Subject: Re: getpeername returning ENOTCONN for a connected socket 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, 23 Jan 2011 20:09:48 -0000 ----- Original Message ----- From: "Steven Hartland" ... > Now given no previous errors from either connect, send or recv > if the connection has been terminated by the other end, which > tcpdump shows its has (RST), I would expect to get ECONNRESET > from getpeername and not ENOTCONN. > > The only case I would expect ENOTCONN is if either no connect > call had been made or if it was unsuccessful. > > Am I missing something here, is ENOTCONN and expected result > from a previously connected socket with no other indication > of error? After doing some more digging the issue may be in sys/kern/uipc_syscalls.c: kern_getpeername where it checks against so_state for SS_ISCONNECTED which can of course be true if the socket was never connected as well as if the socket has been reset by the peer. Should the following code: if ((so->so_state & (SS_ISCONNECTED|SS_ISCONFIRMING)) == 0) { error = ENOTCONN; goto done; } become something like: if ((so->so_state & (SS_ISCONNECTED|SS_ISCONFIRMING)) == 0) { if ((so->so_state & SS_ISDISCONNECTED) == 0) { error = ECONNRESET; } else { error = ENOTCONN; } goto done; } This would obviously report ECONNRESET for shutdown sockets as well as sockets reset by the peer, but I cant see an easy way to distinguish between these two cases without adding a new state value specifically for reset. Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-net@FreeBSD.ORG Sun Jan 23 21:37:04 2011 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 B4BD9106566B; Sun, 23 Jan 2011 21:37:04 +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 8B80B8FC13; Sun, 23 Jan 2011 21:37:04 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p0NLb4RO076762; Sun, 23 Jan 2011 21:37:04 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p0NLb48X076758; Sun, 23 Jan 2011 21:37:04 GMT (envelope-from linimon) Date: Sun, 23 Jan 2011 21:37:04 GMT Message-Id: <201101232137.p0NLb48X076758@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-amd64@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/154236: [re] High Collision count on "re" network interface X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jan 2011 21:37:04 -0000 Old Synopsis: High Collision count on "re" network interface New Synopsis: [re] High Collision count on "re" network interface Responsible-Changed-From-To: freebsd-amd64->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun Jan 23 21:36:46 UTC 2011 Responsible-Changed-Why: reclassify. http://www.freebsd.org/cgi/query-pr.cgi?pr=154236 From owner-freebsd-net@FreeBSD.ORG Sun Jan 23 21:38:46 2011 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 51DA7106564A; Sun, 23 Jan 2011 21:38:46 +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 2853B8FC0A; Sun, 23 Jan 2011 21:38:46 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p0NLckX7077028; Sun, 23 Jan 2011 21:38:46 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p0NLcki9077024; Sun, 23 Jan 2011 21:38:46 GMT (envelope-from linimon) Date: Sun, 23 Jan 2011 21:38:46 GMT Message-Id: <201101232138.p0NLcki9077024@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-amd64@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/154134: [ip6] stuck kernel state in LISTEN on ipv6 daemon which has been killed 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, 23 Jan 2011 21:38:46 -0000 Old Synopsis: stuck kernel state in LISTEN on ipv6 daemon which has been killed New Synopsis: [ip6] stuck kernel state in LISTEN on ipv6 daemon which has been killed Responsible-Changed-From-To: freebsd-amd64->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun Jan 23 21:38:22 UTC 2011 Responsible-Changed-Why: Reclassify. http://www.freebsd.org/cgi/query-pr.cgi?pr=154134 From owner-freebsd-net@FreeBSD.ORG Sun Jan 23 22:10:09 2011 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 564B81065670 for ; Sun, 23 Jan 2011 22:10:09 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 3AD908FC17 for ; Sun, 23 Jan 2011 22:10:09 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p0NMA9aY011021 for ; Sun, 23 Jan 2011 22:10:09 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p0NMA9Lf011020; Sun, 23 Jan 2011 22:10:09 GMT (envelope-from gnats) Date: Sun, 23 Jan 2011 22:10:09 GMT Message-Id: <201101232210.p0NMA9Lf011020@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: "Bjoern A. Zeeb" Cc: Subject: Re: kern/154134: [ip6] stuck kernel state in LISTEN on ipv6 daemon which has been killed X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Bjoern A. Zeeb" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jan 2011 22:10:09 -0000 The following reply was made to PR kern/154134; it has been noted by GNATS. From: "Bjoern A. Zeeb" To: bug-followup@FreeBSD.org, ggm@apnic.net Cc: Subject: Re: kern/154134: [ip6] stuck kernel state in LISTEN on ipv6 daemon which has been killed Date: Sun, 23 Jan 2011 22:03:33 +0000 (UTC) Him unfortunately you didn't give any of the output; I guess you lost it with the reboot and don't have a scrollback? I am not exactly sure about the details that happened: 1) you ran rsync standalon in daemon mode 2) you tried to connect by IPv6 which failed? - How? 3) killed rsync 4) what exact state was netstat showing? Was rsync really all gone? 5) you added what exactly to inetd.conf? -- Bjoern A. Zeeb You have to have visions! Going to jail sucks -- All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html From owner-freebsd-net@FreeBSD.ORG Sun Jan 23 22:55:44 2011 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 EDE8D1065674; Sun, 23 Jan 2011 22:55:44 +0000 (UTC) (envelope-from yongari@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id DEC448FC29; Sun, 23 Jan 2011 22:55:44 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p0NMtiQs061593; Sun, 23 Jan 2011 22:55:44 GMT (envelope-from yongari@freefall.freebsd.org) Received: (from yongari@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p0NMtipG061589; Sun, 23 Jan 2011 22:55:44 GMT (envelope-from yongari) Date: Sun, 23 Jan 2011 22:55:44 GMT Message-Id: <201101232255.p0NMtipG061589@freefall.freebsd.org> To: alex@ahhyes.net, yongari@FreeBSD.org, freebsd-net@FreeBSD.org, yongari@FreeBSD.org From: yongari@FreeBSD.org Cc: Subject: Re: kern/154236: [re] High Collision count on "re" network interface X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jan 2011 22:55:45 -0000 Synopsis: [re] High Collision count on "re" network interface State-Changed-From-To: open->feedback State-Changed-By: yongari State-Changed-When: Sun Jan 23 22:54:37 UTC 2011 State-Changed-Why: The counter comes from status report from hardware so I think the counter is correct. Since you're using auto-negotiation, please make sure link partner also agrees on the resolved speed/duplex of re(4). Show me the output of dmesg for re(4)/rgephy(4). Also include the output of hardware MAC statistics counter. You can get it on your console after executing the following command. #sysctl dev.re.0.stats=1 Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Sun Jan 23 22:54:37 UTC 2011 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=154236 From owner-freebsd-net@FreeBSD.ORG Mon Jan 24 01:08:51 2011 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 81A37106566B for ; Mon, 24 Jan 2011 01:08:51 +0000 (UTC) (envelope-from ptyll@nitronet.pl) Received: from mail.nitronet.pl (smtp.nitronet.pl [195.90.106.27]) by mx1.freebsd.org (Postfix) with ESMTP id 3FA768FC1E for ; Mon, 24 Jan 2011 01:08:50 +0000 (UTC) Received: from mailnull by mail.nitronet.pl with virscan (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PhAvK-0000Xb-8t for freebsd-net@freebsd.org; Mon, 24 Jan 2011 02:08:50 +0100 Date: Mon, 24 Jan 2011 02:08:48 +0100 From: Pawel Tyll X-Priority: 3 (Normal) Message-ID: <13247006.20110124020848@nitronet.pl> To: Brandon Gooch In-Reply-To: References: <201953550.20110106221821@nitronet.pl> <57312439.20110107171430@nitronet.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Nitronet.pl X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: ptyll@nitronet.pl X-SA-Exim-Scanned: No (on mail.nitronet.pl); SAEximRunCond expanded to false Cc: freebsd-net@freebsd.org, Luigi Rizzo , Jack Vogel , freebsd-ipfw@freebsd.org Subject: Re: [Panic] Dummynet/IPFW related recurring crash. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 01:08:51 -0000 On Fri, Jan 7, 2011, Brandon Gooch wrote: > It's likely that the mbuf handling problem (in em_refresh_mbufs()) is > triggered by the processing you're doing with ipfw (or elsewhere for > that matter), so, yes, I think it's a bug fixed in the revision > discussed. > When you update and test, please let us know. Also, don't forget to > submit a follow-up to your PR. Unfortunately bad news: Machine fell after 14 days, 22:31:42 for the same reason according to what was left of panic screen. It didn't do a dump, nor reboot as is customary since some time on S3420GP boards (and other Intel server boards, since colleague has dual-cpu board from same epoch). What can I try next? From owner-freebsd-net@FreeBSD.ORG Mon Jan 24 01:10:13 2011 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 25B6810656A9 for ; Mon, 24 Jan 2011 01:10:13 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 92C118FC1D for ; Mon, 24 Jan 2011 01:10:12 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p0O1AClg003680 for ; Mon, 24 Jan 2011 01:10:12 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p0O1ACcY003679; Mon, 24 Jan 2011 01:10:12 GMT (envelope-from gnats) Date: Mon, 24 Jan 2011 01:10:12 GMT Message-Id: <201101240110.p0O1ACcY003679@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Pawel Tyll Cc: Subject: Re: kern/152360: [dummynet] [panic] Crash related to dummynet. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Pawel Tyll List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 01:10:13 -0000 The following reply was made to PR kern/152360; it has been noted by GNATS. From: Pawel Tyll To: bug-followup@FreeBSD.org Cc: Brandon Gooch Subject: Re: kern/152360: [dummynet] [panic] Crash related to dummynet. Date: Mon, 24 Jan 2011 02:04:10 +0100 Machine fell after 14 days, 22:31:42 for the same reason according to what was left of panic screen. It didn't do a dump, nor reboot as is customary since some time on S3420GP boards. It was NOT fixed by mentioned commit :( What can I try next? From owner-freebsd-net@FreeBSD.ORG Mon Jan 24 02:50:13 2011 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 68EBF106564A for ; Mon, 24 Jan 2011 02:50:13 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 3D2D48FC08 for ; Mon, 24 Jan 2011 02:50:13 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p0O2oDuG008543 for ; Mon, 24 Jan 2011 02:50:13 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p0O2oD3f008541; Mon, 24 Jan 2011 02:50:13 GMT (envelope-from gnats) Date: Mon, 24 Jan 2011 02:50:13 GMT Message-Id: <201101240250.p0O2oD3f008541@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: George Michaelson Cc: Subject: Re: kern/154134: [ip6] stuck kernel state in LISTEN on ipv6 daemon which has been killed X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: George Michaelson List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 02:50:13 -0000 The following reply was made to PR kern/154134; it has been noted by GNATS. From: George Michaelson To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/154134: [ip6] stuck kernel state in LISTEN on ipv6 daemon which has been killed Date: Mon, 24 Jan 2011 12:44:07 +1000 On 24/01/2011, at 8:03 AM, Bjoern A. Zeeb wrote: > Him >=20 > unfortunately you didn't give any of the output; I guess you lost it > with the reboot and don't have a scrollback? right. sad. >=20 > I am not exactly sure about the details that happened: >=20 > 1) you ran rsync standalon in daemon mode yes. > 2) you tried to connect by IPv6 which failed? - How? SYN, but no reply. client then falls back to nd and thats bizarre, but = what happened. multiple times btw. > 3) killed rsync yes. > 4) what exact state was netstat showing? Was rsync really all gone? tcp6 0 0 *.873 *.* LISTEN not in a FIN_WAIT_2 or TIMEOUT or anything. pstree showed no process in zombie. > 5) you added what exactly to inetd.conf? rsync stream tcp6 nowait root /usr/local/bin/rsync rsyncd = --daemon -6 Look, My gut feel is that this was a one-off.=20 If you get other people saying hmm.. some net trash is left active in = the kernel in V6 sometimes then this might be useful debug of when it = was seen in a kernel, but at this point it cleared across reboot, and I = have no further debug I can give. I can't reproduce. mark it stalled or close? -G= From owner-freebsd-net@FreeBSD.ORG Mon Jan 24 05:05:02 2011 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 03A06106564A; Mon, 24 Jan 2011 05:05:01 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C9C188FC18; Mon, 24 Jan 2011 05:05:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p0O55118063778; Mon, 24 Jan 2011 05:05:01 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p0O551LD063774; Mon, 24 Jan 2011 05:05:01 GMT (envelope-from linimon) Date: Mon, 24 Jan 2011 05:05:01 GMT Message-Id: <201101240505.p0O551LD063774@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/154214: [stf] [panic] Panic when creating stf interface X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 05:05:02 -0000 Synopsis: [stf] [panic] Panic when creating stf interface Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Jan 24 05:04:52 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=154214 From owner-freebsd-net@FreeBSD.ORG Mon Jan 24 06:13:25 2011 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 E9D721065670 for ; Mon, 24 Jan 2011 06:13:25 +0000 (UTC) (envelope-from alex@zagrebin.ru) Received: from mail.zagrebin.ru (gw.zagrebin.ru [91.215.205.128]) by mx1.freebsd.org (Postfix) with ESMTP id 92BDA8FC0C for ; Mon, 24 Jan 2011 06:13:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=zagrebin.ru; s=mail; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=H+MMucMdn1NG0rFTuBzSVuRGZjCfL0sveLoPKxDdXxs=; b=ixknirvU5uAGiFVwEQMPcAAoVqMbI/OarA+5Grd6mp+D4R1HogqGoCP1jG9AvQJqomebTui0jSlNJzBGaF2xPgmv++Nue5+5BdN/jAggu/QEn/eEoatNPFx4edpPoiDH/K4GB2bRA+tAbCIBwbC+gMPOPzslM1xpaQ/OAPyW12Y=; Received: from alex by mail.zagrebin.ru with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PhFg2-0007e9-H4; Mon, 24 Jan 2011 09:13:22 +0300 Date: Mon, 24 Jan 2011 09:13:22 +0300 From: Alexander Zagrebin To: "Bjoern A. Zeeb" Message-ID: <20110124061321.GA67220@gw.zagrebin.ru> References: <20110123161137.A3489@maildrop.int.zabbadoz.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110123161137.A3489@maildrop.int.zabbadoz.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@freebsd.org Subject: Re: NAT-T/UDPENCAP patch from stable/7 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 06:13:26 -0000 Hi! On 23.01.2011 16:13:48 +0000, Bjoern A. Zeeb wrote: > here is a version of the NAT-T/UDPENCAP patch as in 8 and 9 for > today's stable/7 for anyone who might want/need it. I would > expect it will equally apply to 7.4-RELEASE once that happened. > > http://people.freebsd.org/~bz/20110123-01-stable7-natt.diff > > You will need to figure out the right version of ipsec-tools or other > IKE clients yourself though. Until now (at least on the 8.2-PRERELEASE) the setkey from the base distribution doesn't dump the SAD entries (`setkey -D`) if NAT-T is used. It reports: "Invalid extension type". Will be this fixed? -- Alexander Zagrebin From owner-freebsd-net@FreeBSD.ORG Mon Jan 24 11:07:05 2011 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 B05CF1065694 for ; Mon, 24 Jan 2011 11:07:05 +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 9DCEF8FC21 for ; Mon, 24 Jan 2011 11:07:05 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p0OB75hX077869 for ; Mon, 24 Jan 2011 11:07:05 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p0OB74lt077867 for freebsd-net@FreeBSD.org; Mon, 24 Jan 2011 11:07:04 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 24 Jan 2011 11:07:04 GMT Message-Id: <201101241107.p0OB74lt077867@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, 24 Jan 2011 11:07:05 -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/154214 net [stf] [panic] Panic when creating stf interface o kern/154134 net [ip6] stuck kernel state in LISTEN on ipv6 daemon whic o kern/154091 net [netgraph] [panic] netgraph, unaligned mbuf? o kern/154006 net [tcp] [patch] tcp "window probe" bug on 64bit o kern/153951 net [ixgbe] Intel 10GBase-LR Ethernet card detected as 10G o kern/153938 net [run] [panic] [patch] Workaround for use-after-free pa 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/153671 net [em] [panic] 8.2-PRERELEASE repeatable kernel in if_em 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/153255 net [panic] 8.2-PRERELEASE repeatable kernel panic under h 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/152360 net [dummynet] [panic] Crash related to dummynet. o kern/152235 net [arp] Permanent local ARP entries are not properly upd o kern/152141 net [vlan] encapsulate vlan in ng_ether before output to i 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 bin/150642 net netstat(1) doesn't print anything for SCTP sockets 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 kern/150247 net [patch] [ixgbe] Version in -current won't build on 7.x 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/149786 net [bwn] bwn on Dell Inspiron 1150: connections stall 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/149539 net [ath] atheros ar9287 is not supported by ath_hal o kern/149516 net [ath] ath(4) hostap with fake MAC/BSSID results in sta o kern/149373 net [realtek/atheros]: None of my network card working o kern/149307 net [ath] Doesn't work Atheros 9285 o kern/149306 net [alc] Doesn't work Atheros AR8131 PCIe Gigabit Etherne o kern/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148322 net [ath] Triggering atheros wifi beacon misses in hostap o kern/148317 net [ath] FreeBSD 7.x hostap memory leak in net80211 or At o kern/148078 net [ath] wireless networking stops functioning 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 o kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146759 net [cxgb] [patch] cxgb panic calling cxgb_set_lro() witho o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146534 net [icmp6] wrong source address in echo reply o kern/146427 net [mwl] Additional virtual access points don't work on m o kern/146426 net [mwl] 802.11n rates not possible on mwl o kern/146425 net [mwl] mwl dropping all packets during and after high u f kern/146394 net [vlan] IP source address for outgoing connections o bin/146377 net [ppp] [tun] Interface doesn't clear addresses when PPP o kern/146358 net [vlan] wrong destination MAC address o kern/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 bin/145934 net [patch] add count option to netstat(1) o kern/145826 net [ath] Unable to configure adhoc mode on ath0/wlan0 o kern/145825 net [panic] panic: soabort: so_count o kern/145728 net [lagg] Stops working lagg between two servers. o kern/144987 net [wpi] [panic] injecting packets with wlaninject using 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/144642 net [rum] [panic] Enabling rum interface causes panic o kern/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 o kern/144572 net [carp] CARP preemption mode traffic partially goes to f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/143939 net [ipfw] [em] ipfw nat and em interface rxcsum problem o kern/143874 net [wpi] Wireless 3945ABG error. wpi0 could not allocate o kern/143868 net [ath] [patch] [request] allow Atheros watchdog timeout 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 conf/143079 net hostapd(8) startup missing multi wlan functionality 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 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/141023 net [carp] CARP arp replays with wrong src mac o kern/140796 net [ath] [panic] privileged instruction fault 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/140245 net [ath] [panic] Kernel panic during network activity on o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/139565 net [ipfilter] ipfilter ioctl SIOCDELST broken o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL o kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/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/138620 net [lagg] [patch] lagg port bpf-writes blocked o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR if_adata/ o kern/138266 net [panic] kernel panic when udp benchmark test used as r o kern/138177 net [ipfilter] FreeBSD crashing repeatedly in ip_nat.c:257 o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 o 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 kern/137775 net [netgraph] [patch] Add XMIT_FAILOVER to ng_one2many o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137592 net [ath] panic - 7-STABLE (Aug 7, 2009 UTC) crashes on ne o bin/137484 net [patch] Integer overflow in wpa_supplicant(8) base64 e o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136943 net [wpi] [lor] wpi0_com_lock / wpi0 o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136836 net [ath] atheros card stops functioning after about 12 ho o bin/136661 net [patch] ndp(8) ignores -f option o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/136426 net [panic] spawning several dhclients in parallel panics o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/134931 net [route] Route messages sent to all socket listeners re o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134168 net [ral] ral driver problem on RT2525 2.4GHz transceiver o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/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 o kern/133218 net [carp] [hang] use of carp(4) causes system to freeze f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/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/132722 net [ath] Wifi ath0 associates fine with AP, but DHCP or I o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132285 net [carp] alias gives incorrect hash in dmesg o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/132107 net [carp] carp(4) advskew setting ignored when carp IP us o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o kern/131549 net ifconfig(8) can't clear 'monitor' mode on the wireless o 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/129750 net [ath] Atheros AR5006 exits on "cannot map register spa f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow o kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/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 conf/128334 net [request] use wpa_cli in the "WPA DHCP" situation o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg o kern/125721 net [ath] Terrible throughput/high ping latency with Ubiqu o kern/125617 net [ath] [panic] ath(4) related panic o kern/125501 net [ath] atheros cardbus driver hangs f kern/125442 net [carp] [lagg] CARP combined with LAGG causes system pa f kern/125332 net [ath] [panic] crash under any non-tiny networking unde o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/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 kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo 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 f kern/123045 net [ng_mppc] ng_mppc_decompress - disabling node 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/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/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 p docs/120945 net [patch] ip6(4) man page lacks documentation for TCLASS o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/118727 net [netgraph] [patch] [request] add new ng_pf module s kern/117717 net [panic] Kernel panic with Bittorrent client. o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111457 net [ral] ral(4) freeze o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/107944 net [wi] [patch] Forget to unlock mutex-locks f kern/107279 net [ath] [panic] ath_start: attempted use of a free mbuf! 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] f kern/105348 net [ath] ath device stopps TX o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o kern/102540 net [netgraph] [patch] supporting vlan(4) by ng_fec(4) o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working 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/93886 net [ath] Atheros/D-Link DWL-G650 long delay to associate f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi 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 s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if 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 s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86871 net [tcp] [patch] allocation logic for PCBs in TIME_WAIT s o kern/86427 net [lor] Deadlock with FASTIPSEC and nat o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ 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 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/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/78968 net FreeBSD freezes on mbufs exhaustion (network interface o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o kern/77341 net [ip6] problems with IPV6 implementation o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time a kern/71474 net [route] route lookup does not skip interfaces marked d o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/66225 net [netgraph] [patch] extend ng_eiface(4) control message o kern/65616 net IPSEC can't detunnel GRE packets after real ESP encryp s kern/60293 net [patch] FreeBSD arp poison patch a kern/56233 net IPsec tunnel (ESP) over IPv6: MTU computation is wrong o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [arp] [patch] for static ARP tables in rc.network 366 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Jan 24 13:00:24 2011 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 7AF951065693 for ; Mon, 24 Jan 2011 13:00:24 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 4F4948FC19 for ; Mon, 24 Jan 2011 13:00:24 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p0OD0Nv2000386 for ; Mon, 24 Jan 2011 13:00:23 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p0OD0Ndr000364; Mon, 24 Jan 2011 13:00:23 GMT (envelope-from gnats) Date: Mon, 24 Jan 2011 13:00:23 GMT Message-Id: <201101241300.p0OD0Ndr000364@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Andrey Simonenko Cc: Subject: Re: kern/92880: [libc] [patch] almost rewritten inet_network(3) function X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Andrey Simonenko List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 13:00:24 -0000 The following reply was made to PR kern/92880; it has been noted by GNATS. From: Andrey Simonenko To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/92880: [libc] [patch] almost rewritten inet_network(3) function Date: Mon, 24 Jan 2011 14:56:25 +0200 Since all '=' were changed to '=3D' in previous email, here is the copy of diff for the inet_network.c file. --- inet_network.c.orig 2008-01-15 00:55:20.000000000 +0200 +++ inet_network.c 2011-01-21 15:58:17.000000000 +0200 @@ -48,57 +48,56 @@ __FBSDID("$FreeBSD: src/lib/libc/inet/in * network numbers. */ in_addr_t -inet_network(cp) - const char *cp; +inet_network(const char *s) { - in_addr_t val, base, n; - char c; - in_addr_t parts[4], *pp = parts; - int i, digit; + u_int base, dots; + in_addr_t res, val; + u_char c; + char got_data; -again: - val = 0; base = 10; digit = 0; - if (*cp == '0') - digit = 1, base = 8, cp++; - if (*cp == 'x' || *cp == 'X') - base = 16, cp++; - while ((c = *cp) != 0) { - if (isdigit((unsigned char)c)) { - if (base == 8U && (c == '8' || c == '9')) + res = 0; + dots = 0; + for (;;) { + val = 0; + got_data = 0; + if (*s == '0') { + s++; + if (*s == 'x' || *s == 'X') { + s++; + base = 16; + } else { + base = 8; + got_data = 1; + } + } else + base = 10; + while ((c = *s) != '\0') { + if (isdigit(c)) { + if (base == 8 && c > '7') + return (INADDR_NONE); + val = val * base + c - '0'; + } else if (base == 16 && isxdigit(c)) + val = (val << 4) + c + 10 - + (islower(c) ? 'a' : 'A'); + else + break; + if (val > 0xff) return (INADDR_NONE); - val = (val * base) + (c - '0'); - cp++; - digit = 1; - continue; + s++; + got_data = 1; } - if (base == 16U && isxdigit((unsigned char)c)) { - val = (val << 4) + - (c + 10 - (islower((unsigned char)c) ? 'a' : 'A')); - cp++; - digit = 1; - continue; - } - break; - } - if (!digit) - return (INADDR_NONE); - if (pp >= parts + 4 || val > 0xffU) - return (INADDR_NONE); - if (*cp == '.') { - *pp++ = val, cp++; - goto again; - } - if (*cp && !isspace(*cp&0xff)) - return (INADDR_NONE); - *pp++ = val; - n = pp - parts; - if (n > 4U) - return (INADDR_NONE); - for (val = 0, i = 0; i < n; i++) { - val <<= 8; - val |= parts[i] & 0xff; + if (!got_data) + return (INADDR_NONE); + if (dots != 0) + res <<= 8; + res |= val; + if (c != '.') + break; + if (++dots == 4) + return (INADDR_NONE); + s++; } - return (val); + return (c == '\0' ? res : INADDR_NONE); } /* From owner-freebsd-net@FreeBSD.ORG Mon Jan 24 13:40:29 2011 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 4EE89106566B for ; Mon, 24 Jan 2011 13:40:29 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp4.dlr.de (smtp3.dlr.de [129.247.252.33]) by mx1.freebsd.org (Postfix) with ESMTP id DAB8C8FC15 for ; Mon, 24 Jan 2011 13:40:28 +0000 (UTC) Received: from DLREXHUB01.intra.dlr.de ([172.21.152.130]) by smtp4.dlr.de with Microsoft SMTPSVC(6.0.3790.4675); Mon, 24 Jan 2011 14:28:24 +0100 Received: from beagle.kn.op.dlr.de (129.247.178.136) by smtp.dlr.de (172.21.152.151) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 24 Jan 2011 14:28:23 +0100 Date: Mon, 24 Jan 2011 14:28:21 +0100 From: Harti Brandt X-X-Sender: brandt_h@beagle.kn.op.dlr.de To: Eugene Grosbein In-Reply-To: <4D3B20C0.8090907@rdtc.ru> Message-ID: <20110124141752.U47002@beagle.kn.op.dlr.de> References: <4D3B20C0.8090907@rdtc.ru> X-OpenPGP-Key: harti@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Originating-IP: [129.247.178.136] X-OriginalArrivalTime: 24 Jan 2011 13:28:24.0243 (UTC) FILETIME=[937D2030:01CBBBCA] Cc: "net@freebsd.org" Subject: Re: bsnmpd: ifTable and if_nametoindex() inconsistency X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Harti Brandt List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 13:40:29 -0000 On Sat, 22 Jan 2011, Eugene Grosbein wrote: EG>I run 8.2-PRERELEASE with bsnmpd and mpd55 serving PPPoE users. EG>I've noticed that sometimes snmpwalk shows interface indexes EG>that partially differ from what if_nametoindex(3) returns EG>with off-by-one or off-by-two. For example, just now this server has EG>813 connected PPPoE sessions (interfaces named ngXXXX) EG>and SNMP returns wrong indexes for 567 out of them, starting from ng334. EG> EG>I've restarted bsnmpd but this made it worse: now all dynamic ngXXXX EG>interfaces have obtained new indexes in SNMP ifTable and no one EG>equals to if_nametoindex(name). EG> EG>Aren't these indexes supposed to be equal? EG>I really need quick method to obtain SNMP index within mpd55 code EG>(for my local mpd hacks) and if_nametoindex() used to seem nice way... EG>I need to export indexes via mpd's web interface so that they may be EG>checked remotely using SNMP. The problem is that the RFC which defines the ifTable puts some interesting restrictions on the ifIndex. For example, the same interface must get the same index if it is removed and inserted again (without the RFC actually describing what means 'same'). Somewhere in the bsnmp code or the man page there is a discussion on this. What it does is: it remembers the ifIndex <-> MAC address mapping and remaps the interface indexes so that this mapping remains constant. This also means, that an interface index is never reused for another interface. So, unless you reboot the system, the same index means always the same interface (identified by MAC address), which is probably a good thing. For 'virtual' interfaces of all kinds there is never the same interface - each interface is a new one and the index is just incremented for each new interface. Since I implemented this I'm torn apart whether this is a good idea or not :-( harti From owner-freebsd-net@FreeBSD.ORG Mon Jan 24 13:42:20 2011 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 468A61065672 for ; Mon, 24 Jan 2011 13:42:20 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp2.dlr.de (smtp1.dlr.de [129.247.252.32]) by mx1.freebsd.org (Postfix) with ESMTP id CDF8B8FC15 for ; Mon, 24 Jan 2011 13:42:19 +0000 (UTC) Received: from DLREXHUB01.intra.dlr.de ([172.21.152.130]) by smtp2.dlr.de with Microsoft SMTPSVC(6.0.3790.4675); Mon, 24 Jan 2011 14:33:16 +0100 Received: from beagle.kn.op.dlr.de (129.247.178.136) by smtp.dlr.de (172.21.152.151) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 24 Jan 2011 14:33:15 +0100 Date: Mon, 24 Jan 2011 14:33:16 +0100 From: Harti Brandt X-X-Sender: brandt_h@beagle.kn.op.dlr.de To: Eugene Grosbein In-Reply-To: <4D3C43EE.8060307@rdtc.ru> Message-ID: <20110124143206.V47002@beagle.kn.op.dlr.de> References: <4D3C43EE.8060307@rdtc.ru> X-OpenPGP-Key: harti@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Originating-IP: [129.247.178.136] X-OriginalArrivalTime: 24 Jan 2011 13:33:16.0427 (UTC) FILETIME=[41A4DDB0:01CBBBCB] Cc: hackers@freebsd.org, "net@freebsd.org" Subject: Re: Querying bsnmpd through /var/run/snmpd.sock X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Harti Brandt List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 13:42:20 -0000 On Sun, 23 Jan 2011, Eugene Grosbein wrote: EG>bsnmpd running with mibII module opens local socket /var/run/snmpd.sock EG>mentioned in snmp_mibII(3) manual page: EG> EG> The mibII module opens a socket that is used to execute all network EG> related ioctl(2) functions. This socket is globally available under the EG> name mib_netsock. EG> EG>How do I use the socket? I hope to be able to call mib_find_if_sys() function EG>from another process using the socket. Is there a documentation for this? The socket works just like a UDP socket with the additional plus that the daemon knows whether you're root or not. As I said in my previous mail, easiest would be to implement an additional table with the sysindex as index and ifIndex as a row. harti From owner-freebsd-net@FreeBSD.ORG Mon Jan 24 13:42:21 2011 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 46EB3106564A for ; Mon, 24 Jan 2011 13:42:21 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp2.dlr.de (smtp1.dlr.de [129.247.252.32]) by mx1.freebsd.org (Postfix) with ESMTP id CE34A8FC16 for ; Mon, 24 Jan 2011 13:42:20 +0000 (UTC) Received: from DLREXHUB01.intra.dlr.de ([172.21.152.130]) by smtp2.dlr.de with Microsoft SMTPSVC(6.0.3790.4675); Mon, 24 Jan 2011 14:30:14 +0100 Received: from beagle.kn.op.dlr.de (129.247.178.136) by smtp.dlr.de (172.21.152.151) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 24 Jan 2011 14:30:13 +0100 Date: Mon, 24 Jan 2011 14:30:14 +0100 From: Harti Brandt X-X-Sender: brandt_h@beagle.kn.op.dlr.de To: Eugene Grosbein In-Reply-To: <4D3B255E.1000709@rdtc.ru> Message-ID: <20110124142837.R47002@beagle.kn.op.dlr.de> References: <4D3B20C0.8090907@rdtc.ru> <4D3B255E.1000709@rdtc.ru> X-OpenPGP-Key: harti@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Originating-IP: [129.247.178.136] X-OriginalArrivalTime: 24 Jan 2011 13:30:14.0864 (UTC) FILETIME=[D56C8D00:01CBBBCA] Cc: "net@freebsd.org" Subject: Re: bsnmpd: ifTable and if_nametoindex() inconsistency X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Harti Brandt List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 13:42:21 -0000 On Sat, 22 Jan 2011, Eugene Grosbein wrote: EG>On 23.01.2011 00:24, Eugene Grosbein wrote: EG>> I really need quick method to obtain SNMP index within mpd55 code EG>> (for my local mpd hacks) and if_nametoindex() used to seem nice way... EG>> I need to export indexes via mpd's web interface so that they may be EG>> checked remotely using SNMP. EG> EG>Still wondering how to get SNMP index without way too slow walking ifTable over... We could implement a private table which maps sysindex -> ifIndex. That would then require one GET before accessing ifTable. harti From owner-freebsd-net@FreeBSD.ORG Mon Jan 24 15:10:11 2011 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 CA3461065672 for ; Mon, 24 Jan 2011 15:10:11 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B9F298FC13 for ; Mon, 24 Jan 2011 15:10:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p0OFABMJ039986 for ; Mon, 24 Jan 2011 15:10:11 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p0OFABsC039985; Mon, 24 Jan 2011 15:10:11 GMT (envelope-from gnats) Date: Mon, 24 Jan 2011 15:10:11 GMT Message-Id: <201101241510.p0OFABsC039985@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: John Baldwin Cc: Subject: Re: amd64/154214: Panic when creating stf interface X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John Baldwin List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 15:10:11 -0000 The following reply was made to PR kern/154214; it has been noted by GNATS. From: John Baldwin To: freebsd-amd64@freebsd.org Cc: "Vladislav V. Prodan" , freebsd-gnats-submit@freebsd.org Subject: Re: amd64/154214: Panic when creating stf interface Date: Mon, 24 Jan 2011 08:11:31 -0500 On Friday, January 21, 2011 7:24:08 pm Vladislav V. Prodan wrote: > > >Number: 154214 > >Category: amd64 > >Synopsis: Panic when creating stf interface > >Confidential: no > >Severity: serious > >Priority: high > >Responsible: freebsd-amd64 > >State: open > >Quarter: > >Keywords: > >Date-Required: > >Class: sw-bug > >Submitter-Id: current-users > >Arrival-Date: Sat Jan 22 00:30:08 UTC 2011 > >Closed-Date: > >Last-Modified: > >Originator: Vladislav V. Prodan > >Release: 9.0-CURRENT amd64 > >Organization: > >Environment: > FreeBSD mary-teresa.ZZZ 9.0-CURRENT FreeBSD 9.0-CURRENT #0: Sun Aug 29 19:00:25 EEST 2010 vlad11@mary-teresa.ZZZ:/usr/obj/usr/src/sys/mary- teresa.24 amd64 > > >Description: > After entering the command "ifconfig stf create" - we panic > > # kldstat -v | grep stf > 226 if_stf > > On the internal interface are given two networks ipv6 - /64 and /48. > Service works rtadvd. > Wanted to create a service 6to4. > > http://img521.imageshack.us/img521/8142/dsc00571in.jpg The picture shows a double fault (likely due to infinite recursion on the stack or some code putting too large of an object onto the stack). Can you get a backtrace via 'tr' at the db> prompt and reply with the output? -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Mon Jan 24 15:23:10 2011 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 67F8B1065673 for ; Mon, 24 Jan 2011 15:23:10 +0000 (UTC) (envelope-from universite@ukr.net) Received: from otrada.od.ua (universite-1-pt.tunnel.tserv24.sto1.ipv6.he.net [IPv6:2001:470:27:140::2]) by mx1.freebsd.org (Postfix) with ESMTP id CB9A38FC18 for ; Mon, 24 Jan 2011 15:23:09 +0000 (UTC) Received: from [10.0.0.10] (phenom.otrada.od.ua [10.0.0.10]) (authenticated bits=0) by otrada.od.ua (8.14.4/8.14.4) with ESMTP id p0OFN4PV036476 for ; Mon, 24 Jan 2011 17:23:05 +0200 (EET) (envelope-from universite@ukr.net) X-Authentication-Warning: otrada.od.ua: Host phenom.otrada.od.ua [10.0.0.10] claimed to be [10.0.0.10] Message-ID: <4D3D9954.9070609@ukr.net> Date: Mon, 24 Jan 2011 17:23:00 +0200 From: "Vladislav V. Prodan" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <201101241510.p0OFABsC039985@freefall.freebsd.org> In-Reply-To: <201101241510.p0OFABsC039985@freefall.freebsd.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.3 required=5.0 tests=ALL_TRUSTED,AWL autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mary-teresa.otrada.od.ua X-Virus-Scanned: clamav-milter 0.95.3 at mary-teresa.otrada.od.ua X-Virus-Status: Clean Subject: Re: amd64/154214: Panic when creating stf interface X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 15:23:10 -0000 24.01.2011 17:10, John Baldwin wrote: > The picture shows a double fault (likely due to infinite recursion on the > stack or some code putting too large of an object onto the stack). Can you > get a backtrace via 'tr' at the db> prompt and reply with the output? Following the withdrawal of these lines, the server hangs perfectly still and not react to any action, except "Reset". -- Vladislav V. Prodan VVP24-UANIC +38[067]4584408 +38[099]4060508 vlad11@jabber.ru From owner-freebsd-net@FreeBSD.ORG Mon Jan 24 17:11:14 2011 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 2FB3910656A4; Mon, 24 Jan 2011 17:11:14 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 878B88FC32; Mon, 24 Jan 2011 17:11:13 +0000 (UTC) Received: by ewy24 with SMTP id 24so2044876ewy.13 for ; Mon, 24 Jan 2011 09:11:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=inkRhYBEHV5u2A9+dcK5fyEN3ADJlJwpl31Fql1EcL0=; b=YjC3iSPs8DVf3vUmkLUPURewLe5Gq609ibGWdOvj3oogZYXU8RI+h8yAHIPXs7KKJZ 9hrMDVKWb/0VVdX7CNEZj6ZJUsKI2l7uzo1YSY1O1hGE9urYirIdribdqrXfPEGW4O0M T6tCoopOrHyFOm9UgbwZfasFJeakd9+F0O6y8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Q82li1J/UusT2v5qoM0Idponrx3kB5pRQNu4M4h47fX2QI8615I0T7zucOzmS+ei3l hTw3skX7PYLrmULg0RxpmNlVQ22tyuFDk+GW8lPewAvuXbiZj3RDDrfFdv10YM67qlS5 b1tdZuARao2zFIaj71D5pczypOdXJJedC+p+w= MIME-Version: 1.0 Received: by 10.216.55.145 with SMTP id k17mr2762962wec.48.1295889072086; Mon, 24 Jan 2011 09:11:12 -0800 (PST) Received: by 10.216.36.71 with HTTP; Mon, 24 Jan 2011 09:11:12 -0800 (PST) In-Reply-To: <13247006.20110124020848@nitronet.pl> References: <201953550.20110106221821@nitronet.pl> <57312439.20110107171430@nitronet.pl> <13247006.20110124020848@nitronet.pl> Date: Mon, 24 Jan 2011 11:11:12 -0600 Message-ID: From: Brandon Gooch To: Pawel Tyll Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, Luigi Rizzo , Jack Vogel , freebsd-ipfw@freebsd.org Subject: Re: [Panic] Dummynet/IPFW related recurring crash. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 17:11:14 -0000 On Sun, Jan 23, 2011 at 7:08 PM, Pawel Tyll wrote: > On Fri, Jan 7, 2011, Brandon Gooch wrote: >> It's likely that the mbuf handling problem (in em_refresh_mbufs()) is >> triggered by the processing you're doing with ipfw (or elsewhere for >> that matter), so, yes, I think it's a bug fixed in the revision >> discussed. > >> When you update and test, please let us know. Also, don't forget to >> submit a follow-up to your PR. > > Unfortunately bad news: > > Machine fell after 14 days, 22:31:42 for the same reason according to > what was left of panic screen. It didn't do a dump, nor reboot as is > customary since some time on S3420GP boards (and other Intel server > boards, since colleague has dual-cpu board from same epoch). > > What can I try next? I'm not sure. Perhaps there is another code path in the em(4) driver that leads to the same, bad-pointer state. I'll have to defer to Jack Vogel or Luigi Rizzo for potential insight into the issue. Please provide as much information as possible (even if it comes down to taking a photo of the console, or transcribing the backtrace). FYI, I haven't been able to test this on any of my setups yet... -Brandon From owner-freebsd-net@FreeBSD.ORG Mon Jan 24 17:14:34 2011 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 DA1FE106566C for ; Mon, 24 Jan 2011 17:14:34 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7A8268FC15 for ; Mon, 24 Jan 2011 17:14:34 +0000 (UTC) Received: by gwj21 with SMTP id 21so1427084gwj.13 for ; Mon, 24 Jan 2011 09:14:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=0YWGxfmvtr6UoD1zv6R2IStcj+kcb6EFPsotc3qNF1I=; b=dh+Md5xYQ7EbK3wI8PCNW9uSA3wbI6z31/TWVYZnS9ekquyGyM5ZvF2eY3Uxw64VhL mIFg3wIQyvHu5ZOXeLtqfRKh8hE7jKhdyCndAcs259ZoTQtFN6QW+3FUfOW0QVy9DNkl +h9EafZPS9AU+gnCaNSW8pVnSg3TU1x9A0f/E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=K/T0SKuslLEwsMlrqTpRgszeAoA8fk3NvwG1MT9B4+0R2+BeeEKS1yzlawwu0dB8GE mTGerTJuUjVpUE716s4SWsZg9bivK8k013JiCq9MW0Q2TFs/FIshhJOmaVBNTA4SL69k bTWt3zfpxHZw5146fZcr+kd7AEfrok9OhD/TE= MIME-Version: 1.0 Received: by 10.151.13.9 with SMTP id q9mr4974927ybi.73.1295889273123; Mon, 24 Jan 2011 09:14:33 -0800 (PST) Received: by 10.147.182.20 with HTTP; Mon, 24 Jan 2011 09:14:33 -0800 (PST) In-Reply-To: References: <201953550.20110106221821@nitronet.pl> <57312439.20110107171430@nitronet.pl> <13247006.20110124020848@nitronet.pl> Date: Mon, 24 Jan 2011 09:14:33 -0800 Message-ID: From: Jack Vogel To: Brandon Gooch Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Pawel Tyll , Luigi Rizzo , freebsd-ipfw@freebsd.org, freebsd-net@freebsd.org Subject: Re: [Panic] Dummynet/IPFW related recurring crash. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 17:14:35 -0000 Just replying so you know I'm seeing it, but something that takes 14 days to even happen is NOT going to be an easy one to find. As Brandon said, all the info you can provide please. Jack On Mon, Jan 24, 2011 at 9:11 AM, Brandon Gooch wrote: > On Sun, Jan 23, 2011 at 7:08 PM, Pawel Tyll wrote: > > On Fri, Jan 7, 2011, Brandon Gooch wrote: > >> It's likely that the mbuf handling problem (in em_refresh_mbufs()) is > >> triggered by the processing you're doing with ipfw (or elsewhere for > >> that matter), so, yes, I think it's a bug fixed in the revision > >> discussed. > > > >> When you update and test, please let us know. Also, don't forget to > >> submit a follow-up to your PR. > > > > Unfortunately bad news: > > > > Machine fell after 14 days, 22:31:42 for the same reason according to > > what was left of panic screen. It didn't do a dump, nor reboot as is > > customary since some time on S3420GP boards (and other Intel server > > boards, since colleague has dual-cpu board from same epoch). > > > > What can I try next? > > I'm not sure. Perhaps there is another code path in the em(4) driver > that leads to the same, bad-pointer state. I'll have to defer to Jack > Vogel or Luigi Rizzo for potential insight into the issue. > > Please provide as much information as possible (even if it comes down > to taking a photo of the console, or transcribing the backtrace). > > FYI, I haven't been able to test this on any of my setups yet... > > -Brandon > From owner-freebsd-net@FreeBSD.ORG Mon Jan 24 17:16:51 2011 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 BE4301065674 for ; Mon, 24 Jan 2011 17:16:51 +0000 (UTC) (envelope-from yusheng.huang@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id 88AAE8FC2A for ; Mon, 24 Jan 2011 17:16:51 +0000 (UTC) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id p0OH5twr027386 for ; Mon, 24 Jan 2011 09:05:55 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from 216.52.23.29 ([216.52.23.29]) by bcs-mail03.internal.cacheflow.com ([10.2.2.95]) via Exchange Front-End Server webmail.bluecoat.com ([10.2.2.114]) with Microsoft Exchange Server HTTP-DAV ; Mon, 24 Jan 2011 17:05:49 +0000 MIME-Version: 1.0 X-Mailer: Apple Mail (2.1082) Content-class: urn:content-classes:message Date: Mon, 24 Jan 2011 09:05:48 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: nfe support for jumbo frame Thread-Index: Acu76PNchYbR6MJhShCIr8KrBqfUtQ== From: "Huang, Yusheng" To: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: nfe support for jumbo frame 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, 24 Jan 2011 17:16:51 -0000 Hi all, We have ported nfe driver to our product and when we try to set mtu to = 9000 on nfe interface, it does not work. No jumbo frame buffer were = allocated. Looking at the code, we found the following: In nfe_ioctl: else { NFE_LOCK(sc); ifp->if_mtu =3D ifr->ifr_mtu; if ((ifp->if_drv_flags & IFF_DRV_RUNNING) !=3D 0) =3D=3D> if = IFF_DRV_RUNNING is set, call nfe_init_locked nfe_init_locked(sc); NFE_UNLOCK(sc); } However, in nfe_init_locked, it has the following test: NFE_LOCK_ASSERT(sc); mii =3D device_get_softc(sc->nfe_miibus); if (ifp->if_drv_flags & IFF_DRV_RUNNING) =3D=3D> if IFF_DRV_RUNNING is = set, return return; nfe_stop(ifp); sc->nfe_framesize =3D ifp->if_mtu + NFE_RX_HEADERS; So it ends up doing nothing. Is there something we missed totally on changing the mtu? -yusheng From owner-freebsd-net@FreeBSD.ORG Mon Jan 24 18:25:39 2011 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 95D5C106564A for ; Mon, 24 Jan 2011 18:25:39 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 454CB8FC13 for ; Mon, 24 Jan 2011 18:25:38 +0000 (UTC) Received: by vws9 with SMTP id 9so1907448vws.13 for ; Mon, 24 Jan 2011 10:25:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:date:to:cc:subject:message-id:reply-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=ihiSkKTQ6Bu7CdvNGO4CEd51Q10sHEChc9kOc6tf9kE=; b=WRzzcbcMk4y74n+/SLhupKFN/kUaw2Tx9HTiw1d/26khkwHVQxM/lRdzBTym5tKnSR 7mxQtZ4c0IhaMhsJFio/H7Cm1Brm0+PcJcGPWGDwpCJ8uLpZXh1HFmJJ/UNOKRR8eUpl e8AnTehhtY0atXJQTq/LsId4laNFz4U4DMk+M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=ey4f0ZmoxUIp/YCU0v/hIrHQlq2+o8ymAmsHAzs6M8+s7LP8HthN4a47fNfJDC6JPI r6g2BgSp2RNSpy3xYL+koBlpYsrMDD9aSEbq2Rb719k4PLaJawu3/NpJkH+sn4unjMWc Yk1KLh08Ft6E+BGnhz+AjURzlOnoxZ+zQ9MCQ= Received: by 10.220.190.3 with SMTP id dg3mr1217308vcb.254.1295891707375; Mon, 24 Jan 2011 09:55:07 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id f17sm7950552vbv.6.2011.01.24.09.55.04 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 24 Jan 2011 09:55:05 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 24 Jan 2011 09:55:02 -0800 From: Pyun YongHyeon Date: Mon, 24 Jan 2011 09:55:02 -0800 To: "Huang, Yusheng" Message-ID: <20110124175502.GA5830@michelle.cdnetworks.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: net@freebsd.org Subject: Re: nfe support for jumbo frame X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 18:25:39 -0000 On Mon, Jan 24, 2011 at 09:05:48AM -0800, Huang, Yusheng wrote: > Hi all, > > We have ported nfe driver to our product and when we try to set mtu to 9000 on nfe interface, it does not work. No jumbo frame buffer were allocated. Looking at the code, we found the following: > > In nfe_ioctl: > > else { > NFE_LOCK(sc); > ifp->if_mtu = ifr->ifr_mtu; > if ((ifp->if_drv_flags & IFF_DRV_RUNNING) != 0) ==> if IFF_DRV_RUNNING is set, call nfe_init_locked > nfe_init_locked(sc); > NFE_UNLOCK(sc); > } > However, in nfe_init_locked, it has the following test: > > > NFE_LOCK_ASSERT(sc); > > mii = device_get_softc(sc->nfe_miibus); > > if (ifp->if_drv_flags & IFF_DRV_RUNNING) ==> if IFF_DRV_RUNNING is set, return > > return; > > nfe_stop(ifp); > > sc->nfe_framesize = ifp->if_mtu + NFE_RX_HEADERS; > > So it ends up doing nothing. > > Is there something we missed totally on changing the mtu? > No you're right. Fixed in HEAD(r217794). Thanks for reporting! From owner-freebsd-net@FreeBSD.ORG Mon Jan 24 19:08:50 2011 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 D51011065673 for ; Mon, 24 Jan 2011 19:08:50 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [62.231.161.221]) by mx1.freebsd.org (Postfix) with ESMTP id 3EE738FC14 for ; Mon, 24 Jan 2011 19:08:49 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.4/8.14.4) with ESMTP id p0OJ8i6T076187; Tue, 25 Jan 2011 01:08:44 +0600 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4D3DCE37.1060808@rdtc.ru> Date: Tue, 25 Jan 2011 01:08:39 +0600 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: Harti Brandt References: <4D3B20C0.8090907@rdtc.ru> <4D3B255E.1000709@rdtc.ru> <20110124142837.R47002@beagle.kn.op.dlr.de> In-Reply-To: <20110124142837.R47002@beagle.kn.op.dlr.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Harti Brandt , "net@freebsd.org" Subject: Re: bsnmpd: ifTable and if_nametoindex() inconsistency 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, 24 Jan 2011 19:08:50 -0000 On 24.01.2011 19:30, Harti Brandt wrote: > On Sat, 22 Jan 2011, Eugene Grosbein wrote: > > EG>On 23.01.2011 00:24, Eugene Grosbein wrote: > EG>> I really need quick method to obtain SNMP index within mpd55 code > EG>> (for my local mpd hacks) and if_nametoindex() used to seem nice way... > EG>> I need to export indexes via mpd's web interface so that they may be > EG>> checked remotely using SNMP. > EG> > EG>Still wondering how to get SNMP index without way too slow walking ifTable over... > > We could implement a private table which maps sysindex -> ifIndex. That > would then require one GET before accessing ifTable. That would be nice :-) From owner-freebsd-net@FreeBSD.ORG Mon Jan 24 19:14:27 2011 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 1F980106566B for ; Mon, 24 Jan 2011 19:14:27 +0000 (UTC) (envelope-from ptyll@nitronet.pl) Received: from mail.nitronet.pl (smtp.nitronet.pl [195.90.106.27]) by mx1.freebsd.org (Postfix) with ESMTP id CF3958FC0A for ; Mon, 24 Jan 2011 19:14:26 +0000 (UTC) Received: from mailnull by mail.nitronet.pl with virscan (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PhRrt-000AuL-Uv for freebsd-net@freebsd.org; Mon, 24 Jan 2011 20:14:25 +0100 Date: Mon, 24 Jan 2011 20:14:14 +0100 From: Pawel Tyll X-Priority: 3 (Normal) Message-ID: <814029043.20110124201414@nitronet.pl> To: Jack Vogel In-Reply-To: References: <201953550.20110106221821@nitronet.pl> <57312439.20110107171430@nitronet.pl> <13247006.20110124020848@nitronet.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Nitronet.pl X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: ptyll@nitronet.pl X-SA-Exim-Scanned: No (on mail.nitronet.pl); SAEximRunCond expanded to false Cc: Brandon Gooch , freebsd-ipfw@freebsd.org, Luigi Rizzo , freebsd-net@freebsd.org Subject: Re: [Panic] Dummynet/IPFW related recurring crash. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 19:14:27 -0000 > Just replying so you know I'm seeing it, but something that takes 14 days= to > even happen > is NOT going to be an easy one to find. As Brandon said, all the info you > can provide please. Here's the dump in case you've not seen it before. Somehow 8.1-RELEASE managed to make a proper dump, which became impossible later on. http://www.freebsd.org/cgi/query-pr.cgi?pr=3D152360 I strongly feel that it's related to dummynet. Not only panic seems to always be pointing at it, but also this is the only one of four identical machines, that crashes (and also only one that uses dummynet). From it's neighbor: up 166 days, 18:45 (FreeBSD 8.1-RELEASE) There's also this problem with fail to reboot after panic, and failure to dump properly. I think I have one more spare box laying around somewhere, so I will look into it. I can trace all this panic business back to one thing I started doing: # ipfw pipe list | grep flows | wc -l 2318 # crontab -l (...) */1 * * * * /root/fw/pipestats.sh (...) # cat /root/fw/pipestats.sh /sbin/ipfw pipe list > pipestats-`date "+%Y%m%d-%H%M%S"` Maybe something overflows here? Don't know :( Ruleset itself seems to be as simple as it gets: 00010 1397 106004 deny ip from any to any not antispoof in 00020 70490095 5395475808 fwd [...] ip from table(60) to table(61) 00050 3741 173481 allow tcp from any to [...] dst-port 53 00051 1868319 195628380 allow udp from any to [...] 00059 19993 1043277 deny ip from any to [...] 00100 603380 33725224 deny ip from any to table(10) dst-port 131-13= 9,445 00102 21201 874326 fwd [...] tcp from table(1) to not table(5) d= st-port 80 00103 0 0 fwd [...] tcp from table(2) to not table(5) d= st-port 80 00104 31 2196 fwd [...] tcp from table(3) to not table(5) 00105 4577 296736 deny ip from table(3) to not table(5) 30000 299626026 144893738712 pipe tablearg ip from table(100) to any in 30001 349984632 312762616666 pipe tablearg ip from any to table(101) out 34900 6724440 1768229912 skipto 35001 ip from table(10) to table(10) 35000 344337771 135015696767 fwd [...] ip from 192.168.0.0/16 to not 192.1= 68.0.0/16 65534 1118791481 888359380351 allow ip from any to any 65535 0 0 allow ip from any to any Two weeks seems to be rather strange. It never happens much earlier, and I don't remember panics much later. Too bad I didn't install uptimed back then, would have at least 10 panics recorded now ;) There's something elusive somewhere here, and sad part is it doesn't happen to others. Machine itself isn't really heavy loaded, processing 40-60kpps. Thank you for your interest, I very much appreciate it. From owner-freebsd-net@FreeBSD.ORG Tue Jan 25 13:32:30 2011 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 58DC51065670 for ; Tue, 25 Jan 2011 13:32:30 +0000 (UTC) (envelope-from alex@zagrebin.ru) Received: from mail.zagrebin.ru (gw.zagrebin.ru [91.215.205.128]) by mx1.freebsd.org (Postfix) with ESMTP id 000138FC0C for ; Tue, 25 Jan 2011 13:32:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=zagrebin.ru; s=mail; h=Content-Type:MIME-Version:Message-ID:Subject:To:From:Date; bh=tBANRWsBQIUeMjYOUK0HqqxaiwcLqnEXYvNJSQRHerI=; b=y8msLtfodwSjjVeUobfdSCWqJUm4yI3sSAV60dfTg4kOrb3opCXrS9aUgYRx01EKfUFdfQTCQdCngbJB4KSLbHBGHcd5iiSUIbRNoSOHTbZhOHwM5YuPaiG3DH9nyEg80dgZmU+23k9eho+qH1Y3JlsW5n8Kvbug7c4eTzoSr3M=; Received: from alex by mail.zagrebin.ru with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Phj0V-000FCG-4u for freebsd-net@freebsd.org; Tue, 25 Jan 2011 16:32:27 +0300 Date: Tue, 25 Jan 2011 16:32:26 +0300 From: Alexander Zagrebin To: freebsd-net@freebsd.org Message-ID: <20110125133226.GD67220@gw.zagrebin.ru> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="MW5yreqqjyrRcusr" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: 8.2-PRERELEASE: if_bridge ARP and broadcasts issues 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, 25 Jan 2011 13:32:30 -0000 --MW5yreqqjyrRcusr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi! I've found some issues with the if_bridge on 8.2-PRERELEASE. 1. An ARP issue Suppose we have a box with the 4 interfaces: nic0, nic1, nic2, nic3. The interfaces are linked pairwise using 2 bridge(4) interfaces: bridge0 and bridge1. Only nic0 has an IP address assigned (for example, 192.168.0.1/24). So we have configuration like this: 192.168.0.1 ---nic0---+ +---nic2--- | | bridge0 bridge1 | | ---nic1---+ +---nic3--- The problem: when ARP query about MAC address of 192.168.0.1 is received on the nic2 or nic3, then system responds with the MAC address of the nic0, though networks on the bridge0 and bridge1 are completely independent. IMHO, it isn't correct. The reason is in ARP handling code: it looks for an address of the interface belonging to a bridge, but there is not check that a bridge is the same. Attached patch (patch-if_ether.c) fixes the issue. 2. Broadcasts issue I have a box with two NICs: re0 and wlan0. re0 and wlan0 are members of the bridge0. re0 has IP address 192.168.1.1; wlan0 hasn't an address configured. I have the samba installed. The smbd and nmbd listens on the 192.168.1.1. There are no problems with the clients connected to the re0, but the samba clients connected to the wlan0 has problems with the network browsing and domain logons. I've found that nmbd doesn't receive udp broadcasts received on the wlan0, though bridge0 successfully retransmits this broadcast out of re0. I've looked in the sources, and it seems that in this case subnet broadcasts have to be handled in ether_output(), but this doesn't work anyway... Can anybody help to fix this issue? -- Alexander Zagrebin --MW5yreqqjyrRcusr-- From owner-freebsd-net@FreeBSD.ORG Tue Jan 25 13:42:27 2011 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 69516106564A for ; Tue, 25 Jan 2011 13:42:27 +0000 (UTC) (envelope-from alex@zagrebin.ru) Received: from mail.zagrebin.ru (gw.zagrebin.ru [91.215.205.128]) by mx1.freebsd.org (Postfix) with ESMTP id 186168FC1F for ; Tue, 25 Jan 2011 13:42:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=zagrebin.ru; s=mail; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:To:From:Date; bh=AVYLuBCzN0+Oymq0DrYSa/IUcRvtsBQ1cB8m0HMic6g=; b=JXX/eDBg29WZjf7Kd/eVyleufPE+jeb40K7ElAGD5rAwrjSJDZ1t+rshQuRqUntsBI3UmepWfbXylPqnUzm1i5qvzpfk+lMLDEEV5iWZZUyGx/zoqXGxGu4vU6Plv9meZ2zztvPF7emO6LZUs+JPoqKvOX025YOQl70w/+XRtSc=; Received: from alex by mail.zagrebin.ru with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PhjA9-000FEg-UQ for freebsd-net@freebsd.org; Tue, 25 Jan 2011 16:42:25 +0300 Date: Tue, 25 Jan 2011 16:42:25 +0300 From: Alexander Zagrebin To: freebsd-net@freebsd.org Message-ID: <20110125134225.GE67220@gw.zagrebin.ru> References: <20110125133226.GD67220@gw.zagrebin.ru> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="E13BgyNx05feLLmH" Content-Disposition: inline In-Reply-To: <20110125133226.GD67220@gw.zagrebin.ru> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: 8.2-PRERELEASE: if_bridge ARP and broadcasts issues 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, 25 Jan 2011 13:42:27 -0000 --E13BgyNx05feLLmH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi! On 25.01.2011 16:32:26 +0300, Alexander Zagrebin wrote: > Attached patch (patch-if_ether.c) fixes the issue. It seems the attached file has disappeared. I'll try again... -- Alexander Zagrebin --E13BgyNx05feLLmH Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="patch-if_ether.c" --- sys/netinet/if_ether.c.orig 2011-01-16 21:01:41.000000000 +0300 +++ sys/netinet/if_ether.c 2011-01-25 13:48:47.859914728 +0300 @@ -551,7 +551,7 @@ */ IN_IFADDR_RLOCK(); LIST_FOREACH(ia, INADDR_HASH(itaddr.s_addr), ia_hash) { - if (((bridged && ia->ia_ifp->if_bridge != NULL) || + if (((bridged && ia->ia_ifp->if_bridge == ifp->if_bridge) || ia->ia_ifp == ifp) && itaddr.s_addr == ia->ia_addr.sin_addr.s_addr) { ifa_ref(&ia->ia_ifa); @@ -568,7 +568,7 @@ } } LIST_FOREACH(ia, INADDR_HASH(isaddr.s_addr), ia_hash) - if (((bridged && ia->ia_ifp->if_bridge != NULL) || + if (((bridged && ia->ia_ifp->if_bridge == ifp->if_bridge) || ia->ia_ifp == ifp) && isaddr.s_addr == ia->ia_addr.sin_addr.s_addr) { ifa_ref(&ia->ia_ifa); --E13BgyNx05feLLmH-- From owner-freebsd-net@FreeBSD.ORG Tue Jan 25 15:40:09 2011 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 0BB2D106566C for ; Tue, 25 Jan 2011 15:40:09 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D3ABA8FC16 for ; Tue, 25 Jan 2011 15:40:08 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p0PFe8xi049519 for ; Tue, 25 Jan 2011 15:40:08 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p0PFe8W9049516; Tue, 25 Jan 2011 15:40:08 GMT (envelope-from gnats) Date: Tue, 25 Jan 2011 15:40:08 GMT Message-Id: <201101251540.p0PFe8W9049516@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: "Eduardo Schoedler" Cc: Subject: Re: kern/151593: [igb] [panic] Kernel panic when bringing up igb network adapter with MSI-X enabled X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Eduardo Schoedler List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 15:40:09 -0000 The following reply was made to PR kern/151593; it has been noted by GNATS. From: "Eduardo Schoedler" To: , Cc: Subject: Re: kern/151593: [igb] [panic] Kernel panic when bringing up igb network adapter with MSI-X enabled Date: Tue, 25 Jan 2011 13:22:45 -0200 I have the same problem. Please comment the lines in your /boot/loader.conf and run your tests again. #hw.igb.rxd=4096 #hw.igb.txd=4096 #hw.igb.enable_aim=1 Best regards, -- Eduardo Schoedler From owner-freebsd-net@FreeBSD.ORG Tue Jan 25 16:25:19 2011 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 88F801065696 for ; Tue, 25 Jan 2011 16:25:19 +0000 (UTC) (envelope-from nvass@gmx.com) Received: from mailout-eu.gmx.com (mailout-eu.gmx.com [213.165.64.42]) by mx1.freebsd.org (Postfix) with SMTP id EAEFE8FC14 for ; Tue, 25 Jan 2011 16:25:18 +0000 (UTC) Received: (qmail invoked by alias); 25 Jan 2011 16:25:17 -0000 Received: from john73.static.otenet.gr (EHLO [195.10.10.45]) [85.72.35.251] by mail.gmx.com (mp-eu001) with SMTP; 25 Jan 2011 17:25:17 +0100 X-Authenticated: #46156728 X-Provags-ID: V01U2FsdGVkX1/v1dYx8I3vzZTHfOL6l22Fob3pG6oJEOnxJ77IIx +vs0X6ywGyuTdd Message-ID: <4D3EF966.7010209@gmx.com> Date: Tue, 25 Jan 2011 18:25:10 +0200 From: Nikos Vassiliadis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Alexander Zagrebin References: <20110125133226.GD67220@gw.zagrebin.ru> In-Reply-To: <20110125133226.GD67220@gw.zagrebin.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: freebsd-net@freebsd.org Subject: Re: 8.2-PRERELEASE: if_bridge ARP and broadcasts issues 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, 25 Jan 2011 16:25:19 -0000 On 1/25/2011 3:32 PM, Alexander Zagrebin wrote: > Hi! > > I've found some issues with the if_bridge on 8.2-PRERELEASE. > > 1. An ARP issue > > Suppose we have a box with the 4 interfaces: nic0, nic1, nic2, nic3. > The interfaces are linked pairwise using 2 bridge(4) interfaces: bridge0 > and bridge1. Only nic0 has an IP address assigned (for example, > 192.168.0.1/24). > So we have configuration like this: > > 192.168.0.1 > ---nic0---+ +---nic2--- > | | > bridge0 bridge1 > | | > ---nic1---+ +---nic3--- > > The problem: when ARP query about MAC address of 192.168.0.1 is received > on the nic2 or nic3, then system responds with the MAC address of the nic0, > though networks on the bridge0 and bridge1 are completely independent. > IMHO, it isn't correct. > Yes, I tried the setup and it behaves as you described. > The reason is in ARP handling code: it looks for an address of the interface > belonging to a bridge, but there is not check that a bridge is the same. > > Attached patch (patch-if_ether.c) fixes the issue. > I tried your patch and it works for me. > 2. Broadcasts issue > > I have a box with two NICs: re0 and wlan0. re0 and wlan0 are members of the > bridge0. re0 has IP address 192.168.1.1; wlan0 hasn't an address configured. > I have the samba installed. The smbd and nmbd listens on the 192.168.1.1. > There are no problems with the clients connected to the re0, but the samba > clients connected to the wlan0 has problems with the network browsing and > domain logons. > I've found that nmbd doesn't receive udp broadcasts received on the wlan0, > though bridge0 successfully retransmits this broadcast out of re0. > I've looked in the sources, and it seems that in this case subnet broadcasts > have to be handled in ether_output(), but this doesn't work anyway... > > Can anybody help to fix this issue? As far as I recall, the recommended setup is to assign IP addresses to the bridge interface, not the member interfaces. Could you try this? HTH, Nikos From owner-freebsd-net@FreeBSD.ORG Tue Jan 25 17:42:51 2011 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 936F1106566C for ; Tue, 25 Jan 2011 17:42:51 +0000 (UTC) (envelope-from andy@fud.org.nz) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 35ED58FC19 for ; Tue, 25 Jan 2011 17:42:50 +0000 (UTC) Received: by wwf26 with SMTP id 26so34835wwf.31 for ; Tue, 25 Jan 2011 09:42:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.227.156.67 with SMTP id v3mr6281459wbw.80.1295975755880; Tue, 25 Jan 2011 09:15:55 -0800 (PST) Sender: andy@fud.org.nz Received: by 10.227.11.130 with HTTP; Tue, 25 Jan 2011 09:15:55 -0800 (PST) In-Reply-To: <20110125133226.GD67220@gw.zagrebin.ru> References: <20110125133226.GD67220@gw.zagrebin.ru> Date: Wed, 26 Jan 2011 06:15:55 +1300 X-Google-Sender-Auth: rgCPKaLLhBA4hTtF4a4alBpmnVo Message-ID: From: Andrew Thompson To: Alexander Zagrebin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: 8.2-PRERELEASE: if_bridge ARP and broadcasts issues 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, 25 Jan 2011 17:42:51 -0000 On 26 January 2011 02:32, Alexander Zagrebin wrote: > Hi! > > I've found some issues with the if_bridge on 8.2-PRERELEASE. > > 1. An ARP issue > > Suppose we have a box with the 4 interfaces: nic0, nic1, nic2, nic3. > The interfaces are linked pairwise using 2 bridge(4) interfaces: bridge0 > and bridge1. Only nic0 has an IP address assigned (for example, > 192.168.0.1/24). > So we have configuration like this: > > =A0192.168.0.1 > ---nic0---+ =A0 =A0 =A0 +---nic2--- > =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 | > =A0 =A0 =A0 bridge0 bridge1 > =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 | > ---nic1---+ =A0 =A0 =A0 +---nic3--- > > The problem: when ARP query about MAC address of 192.168.0.1 is received > on the nic2 or nic3, then system responds with the MAC address of the nic= 0, > though networks on the bridge0 and bridge1 are completely independent. > IMHO, it isn't correct. > > The reason is in ARP handling code: it looks for an address of the interf= ace > belonging to a bridge, but there is not check that a bridge is the same. > > Attached patch (patch-if_ether.c) fixes the issue. I have committed this, thanks. From owner-freebsd-net@FreeBSD.ORG Wed Jan 26 05:21:52 2011 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 16666106564A for ; Wed, 26 Jan 2011 05:21:52 +0000 (UTC) (envelope-from alex@zagrebin.ru) Received: from mail.zagrebin.ru (gw.zagrebin.ru [91.215.205.128]) by mx1.freebsd.org (Postfix) with ESMTP id BA4948FC08 for ; Wed, 26 Jan 2011 05:21:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=zagrebin.ru; s=mail; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=fcp0XUNm+mobxAGmoH0TExU0RMlRtthw0CAO2TgqHK8=; b=pLFTnDPE1mtSoC9DGzYWbzKEMnJcuva0gMifP4WlgFo8URlUGcUqGY//lk2gHVKJlEmv0yUB0XlApLyyd5tM2h1jUi/gRalF33lsHq4zycjgYVlENv5DeO2h5D1i+cyxj8g9Kghq7XLw3TMzQjW6J0BYvGuw0CIfrk9J7Wd85Og=; Received: from alex by mail.zagrebin.ru with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PhxpE-000JmZ-JR; Wed, 26 Jan 2011 08:21:48 +0300 Date: Wed, 26 Jan 2011 08:21:48 +0300 From: Alexander Zagrebin To: Nikos Vassiliadis Message-ID: <20110126052147.GF67220@gw.zagrebin.ru> References: <20110125133226.GD67220@gw.zagrebin.ru> <4D3EF966.7010209@gmx.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D3EF966.7010209@gmx.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@freebsd.org Subject: Re: 8.2-PRERELEASE: if_bridge ARP and broadcasts issues 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, 26 Jan 2011 05:21:52 -0000 Hi! On 25.01.2011 18:25:10 +0200, Nikos Vassiliadis wrote: > > The reason is in ARP handling code: it looks for an address of the interface > > belonging to a bridge, but there is not check that a bridge is the same. > > > > Attached patch (patch-if_ether.c) fixes the issue. > > > > I tried your patch and it works for me. Thanks for confirmation! > > > 2. Broadcasts issue > > > > I have a box with two NICs: re0 and wlan0. re0 and wlan0 are members of the > > bridge0. re0 has IP address 192.168.1.1; wlan0 hasn't an address configured. > > I have the samba installed. The smbd and nmbd listens on the 192.168.1.1. > > There are no problems with the clients connected to the re0, but the samba > > clients connected to the wlan0 has problems with the network browsing and > > domain logons. > > I've found that nmbd doesn't receive udp broadcasts received on the wlan0, > > though bridge0 successfully retransmits this broadcast out of re0. > > I've looked in the sources, and it seems that in this case subnet broadcasts > > have to be handled in ether_output(), but this doesn't work anyway... > > > > Can anybody help to fix this issue? > > As far as I recall, the recommended setup is to assign IP addresses to > the bridge interface, not the member interfaces. Could you try this? Yes, when ip address is assigned to bridge0 or inbound interface (wlan0 in this case) then there are no problems. This may be used as workaround, but... As there is no direct interdiction to use addresses bound to a member interfaces, it seems it's a bug. -- Alexander Zagrebin From owner-freebsd-net@FreeBSD.ORG Wed Jan 26 11:07:33 2011 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 6934410656C1; Wed, 26 Jan 2011 11:07:33 +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 3FEF88FC1D; Wed, 26 Jan 2011 11:07:33 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p0QB7XPV032606; Wed, 26 Jan 2011 11:07:33 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p0QB7XsJ032602; Wed, 26 Jan 2011 11:07:33 GMT (envelope-from linimon) Date: Wed, 26 Jan 2011 11:07:33 GMT Message-Id: <201101261107.p0QB7XsJ032602@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/154237: [ath] AR9280 w/ AES-CCMP (WPA2) group key does not work 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, 26 Jan 2011 11:07:33 -0000 Synopsis: [ath] AR9280 w/ AES-CCMP (WPA2) group key does not work Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Jan 26 11:07:24 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=154237 From owner-freebsd-net@FreeBSD.ORG Wed Jan 26 11:11:44 2011 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 BF942106566B; Wed, 26 Jan 2011 11:11:44 +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 95F508FC1A; Wed, 26 Jan 2011 11:11:44 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p0QBBi7r041904; Wed, 26 Jan 2011 11:11:44 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p0QBBidE041900; Wed, 26 Jan 2011 11:11:44 GMT (envelope-from linimon) Date: Wed, 26 Jan 2011 11:11:44 GMT Message-Id: <201101261111.p0QBBidE041900@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/154284: [ath] Modern ath wifi cars (such as AR9285) have missed LED indication 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, 26 Jan 2011 11:11:44 -0000 Synopsis: [ath] Modern ath wifi cars (such as AR9285) have missed LED indication Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Jan 26 11:11:32 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=154284 From owner-freebsd-net@FreeBSD.ORG Wed Jan 26 11:14:12 2011 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 2F046106564A; Wed, 26 Jan 2011 11:14:12 +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 05CE78FC08; Wed, 26 Jan 2011 11:14:12 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p0QBEB0B043305; Wed, 26 Jan 2011 11:14:11 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p0QBEB1r043297; Wed, 26 Jan 2011 11:14:11 GMT (envelope-from linimon) Date: Wed, 26 Jan 2011 11:14:11 GMT Message-Id: <201101261114.p0QBEB1r043297@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/154286: [netgraph] [panic] 8.2-PRERELEASE panic in netgraph 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, 26 Jan 2011 11:14:12 -0000 Synopsis: [netgraph] [panic] 8.2-PRERELEASE panic in netgraph Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Jan 26 11:14:03 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=154286 From owner-freebsd-net@FreeBSD.ORG Wed Jan 26 11:16:57 2011 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 15504106564A; Wed, 26 Jan 2011 11:16:57 +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 E0C8A8FC0C; Wed, 26 Jan 2011 11:16:56 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p0QBGuRV044123; Wed, 26 Jan 2011 11:16:56 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p0QBGuEK044119; Wed, 26 Jan 2011 11:16:56 GMT (envelope-from linimon) Date: Wed, 26 Jan 2011 11:16:56 GMT Message-Id: <201101261116.p0QBGuEK044119@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/154255: [nfs] NFS not responding 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, 26 Jan 2011 11:16:57 -0000 Old Synopsis: NFS not responding New Synopsis: [nfs] NFS not responding Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Jan 26 11:16:01 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=154255 From owner-freebsd-net@FreeBSD.ORG Wed Jan 26 11:54:29 2011 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 66C6A1065679 for ; Wed, 26 Jan 2011 11:54:29 +0000 (UTC) (envelope-from ivo.vachkov@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 196528FC08 for ; Wed, 26 Jan 2011 11:54:28 +0000 (UTC) Received: by qwj9 with SMTP id 9so845100qwj.13 for ; Wed, 26 Jan 2011 03:54:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:from:date:message-id:subject:to :content-type; bh=WGwb+Ht7XMUO5rn6x9+no/qajvvBcRIkdJKX8y5emrM=; b=EFwBbmsb/0yIPA64ytAxQX5XZ99E67chMOKxSbsjZQy9acFBg9SdI9F1HuPIx07qpO alBfbcvIqJhHMHdczSyblxO67hH63SJExgdtn65d9+MnTqIUEfIMIUrkDkqNJ3Bo+NOy oeEO8jtkKseFMOW3ezx2THYiCCdf5ZKhHOADE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=AzlvMEI/U7PaeROFVQ00f4CLZWZuJun6RiEL6oXvEXb/ngKWLaDaaEc4Fcm3xEyAvM k0LDxtaVbNCbct1j/tWLQwZPCv7xKhA0K5MMfg0uO5PRR6Wf4aUnvv78eg21397SeiYh BJN+d1kI6hP0dIenTEIwG8hj3iVNCB5f5HZ1o= Received: by 10.224.89.85 with SMTP id d21mr355117qam.162.1296041307938; Wed, 26 Jan 2011 03:28:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.193.9 with HTTP; Wed, 26 Jan 2011 03:28:07 -0800 (PST) From: Ivo Vachkov Date: Wed, 26 Jan 2011 13:28:07 +0200 Message-ID: To: FreeBSD Net Content-Type: multipart/mixed; boundary=0015175ce06ac62152049abe21a9 Subject: Proposed patch for Port Randomization modifications according to RFC6056 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, 26 Jan 2011 11:54:29 -0000 --0015175ce06ac62152049abe21a9 Content-Type: text/plain; charset=UTF-8 Hello, I would like to propose a patch (against FreeBSD RELENG_8) to extend the port randomization support in FreeBSD, according to RFC6056 (https://www.rfc-editor.org/rfc/rfc6056.txt) Currently the patch implements: - Algorithm 1 (default in FreeBSD 8) - Algorithm 2 - Algorithm 5 from the aforementioned RFC6056. Any of those algorithms can be chosen with the sysctl variable net.inet.ip.portrange.rfc6056_algorithm. I deliberately skipped Algorithm 3 and Algorithm 4, because I believe usage of cryptographic hash functions will introduce unnecessary latency in vital network operations. However, in case of expressed interest, I will be glad to add those too. I would like to ask what is the proper way to validate the sysctl input in order to accept only a specific values? In my case only '1', '2' and '5'. Thank you very much. Ivo Vachkov --0015175ce06ac62152049abe21a9 Content-Type: text/x-patch; charset=US-ASCII; name="freebsd-RELENG_8-rfc6056.patch" Content-Disposition: attachment; filename="freebsd-RELENG_8-rfc6056.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gje4xjku0 ZGlmZiAtciBmYmYxMzEzMzYyZDcgc3JjL3N5cy9uZXRpbmV0L2luX3BjYi5jCi0tLSBhL3NyYy9z eXMvbmV0aW5ldC9pbl9wY2IuYwlUdWUgSmFuIDI1IDE0OjAzOjM3IDIwMTEgKzAyMDAKKysrIGIv c3JjL3N5cy9uZXRpbmV0L2luX3BjYi5jCVdlZCBKYW4gMjYgMTI6NTg6MDUgMjAxMSArMDIwMApA QCAtMTA5LDYgKzEwOSw3IEBACiBWTkVUX0RFRklORShpbnQsIGlwcG9ydF9zdG9wcmFuZG9tKTsJ CS8qIHRvZ2dsZWQgYnkgaXBwb3J0X3RpY2sgKi8KIFZORVRfREVGSU5FKGludCwgaXBwb3J0X3Rj cGFsbG9jcyk7CiBzdGF0aWMgVk5FVF9ERUZJTkUoaW50LCBpcHBvcnRfdGNwbGFzdGNvdW50KTsK K1ZORVRfREVGSU5FKGludCwgaXBwb3J0X3JmYzYwNTZhbGcpID0gMTsJLyogdXNlciBjb250cm9s bGVkIHZpYSBzeXNjdGwgKi8KIAogI2RlZmluZQlWX2lwcG9ydF90Y3BsYXN0Y291bnQJCVZORVQo aXBwb3J0X3RjcGxhc3Rjb3VudCkKIApAQCAtMTc0LDYgKzE3NSw4IEBACiAJJlZORVRfTkFNRShp cHBvcnRfcmFuZG9tdGltZSksIDAsCiAJIk1pbmltdW0gdGltZSB0byBrZWVwIHNlcXVlbnRhbCBw b3J0ICIKIAkiYWxsb2NhdGlvbiBiZWZvcmUgc3dpdGNoaW5nIHRvIGEgcmFuZG9tIG9uZSIpOwor U1lTQ1RMX1ZORVRfSU5UKF9uZXRfaW5ldF9pcF9wb3J0cmFuZ2UsIE9JRF9BVVRPLCByZmM2MDU2 X2FsZ29yaXRobSwgQ1RMRkxBR19SVywKKwkmVk5FVF9OQU1FKGlwcG9ydF9yZmM2MDU2YWxnKSwg MCwgIlJGQyA2MDU2IFBvcnQgcmFuZG9taXphdGlvbiBhbGdvcml0aG0iKTsKIAogLyoKICAqIGlu X3BjYi5jOiBtYW5hZ2UgdGhlIFByb3RvY29sIENvbnRyb2wgQmxvY2tzLgpAQCAtNDY4LDIxICs0 NzEsNzUgQEAKIAkJCWxhc3QgPSBhdXg7CiAJCX0KIAotCQlpZiAoZG9yYW5kb20pCi0JCQkqbGFz dHBvcnQgPSBmaXJzdCArCi0JCQkJICAgIChhcmM0cmFuZG9tKCkgJSAobGFzdCAtIGZpcnN0KSk7 Ci0KIAkJY291bnQgPSBsYXN0IC0gZmlyc3Q7CiAKLQkJZG8gewotCQkJaWYgKGNvdW50LS0gPCAw KQkvKiBjb21wbGV0ZWx5IHVzZWQ/ICovCi0JCQkJcmV0dXJuIChFQUREUk5PVEFWQUlMKTsKLQkJ CSsrKmxhc3Rwb3J0OwotCQkJaWYgKCpsYXN0cG9ydCA8IGZpcnN0IHx8ICpsYXN0cG9ydCA+IGxh c3QpCi0JCQkJKmxhc3Rwb3J0ID0gZmlyc3Q7Ci0JCQlscG9ydCA9IGh0b25zKCpsYXN0cG9ydCk7 Ci0JCX0gd2hpbGUgKGluX3BjYmxvb2t1cF9sb2NhbChwY2JpbmZvLCBsYWRkciwKLQkJICAgIGxw b3J0LCB3aWxkLCBjcmVkKSk7CisJCS8qIAorCQkgKiBBY2NvcmRpbmcgdG8gUkZDNjA1NiB0aGVy ZSBhcmUgNSAoZml2ZSkgcG9zc2libGUgYWxnb3JpdGhtcworCQkgKiBmb3IgcmFuZG9tIHBvcnQg YWxsb2NhdGlvbi4gVXNhZ2Ugb2YgYSBwYXJ0aWN1bGFyIGFsZ29yaXRobQorCQkgKiBpcyBzcGVj aWZpZWQgd2l0aCB0aGUgJ25ldC5pbmV0LmlwLnBvcnRyYW5nZS5yZmM2MDU2X2FsZ29yaXRobScK KwkJICogc3lzY3RsIHZhcmlhYmxlLiBEZWZhdWx0IHZhbHVlIGlzIDEsIHdoaWNoIHJlcHJlc2Vu dHMgdGhlCisJCSAqIGxlZ2FjeSByYW5kb20gcG9ydCBhbGxvY2F0aW9uIGFsZ29yaXRobSBpbiBG cmVlQlNELgorCQkgKi8KKwkJaWYgKGRvcmFuZG9tKSB7CisJCQlzd2l0Y2ggKFZfaXBwb3J0X3Jm YzYwNTZhbGcpIHsKKwkJCWNhc2UgNToJCS8qIFJhbmRvbS1JbmNyZW1lbnRzIFBvcnQgU2VsZWN0 aW9uICovCisJCQkJZG8geworCQkJCQlpZiAoY291bnQtLSA8IDApCS8qIGNvbXBsZXRlbHkgdXNl ZD8gKi8KKwkJCQkJCXJldHVybiAoRUFERFJOT1RBVkFJTCk7CisKKwkJCQkJKmxhc3Rwb3J0ID0g Zmlyc3QgKyAoKGFyYzRyYW5kb20oKSAlIDY1NTM2KSArIAorCQkJCQkgICAgKGFyYzRyYW5kb20o KSAlIDUwMCkgKyAxKTsKKworCQkJCQlpZiAoKmxhc3Rwb3J0IDwgZmlyc3QgfHwgKmxhc3Rwb3J0 ID4gbGFzdCkKKwkJCQkJCSpsYXN0cG9ydCA9IGZpcnN0OworCQkJCQlscG9ydCA9IGh0b25zKCps YXN0cG9ydCk7CisJCQkJfSB3aGlsZSAoaW5fcGNibG9va3VwX2xvY2FsKHBjYmluZm8sIGxhZGRy LAorCQkJCSAgICBscG9ydCwgd2lsZCwgY3JlZCkpOworCisJCQkJYnJlYWs7CisJCQljYXNlIDI6 CQkvKiBTaW1wbGUgUG9ydCBSYW5kb21pemF0aW9uIEFsZ29yaXRobSBJSSAqLworCQkJCWRvIHsK KwkJCQkJaWYgKGNvdW50LS0gPCAwKQkvKiBjb21wbGV0ZWx5IHVzZWQ/ICovCisJCQkJCQlyZXR1 cm4gKEVBRERSTk9UQVZBSUwpOworCisJCQkJCSpsYXN0cG9ydCA9IGZpcnN0ICsgKGFyYzRyYW5k b20oKSAlIChsYXN0IC0gZmlyc3QpKTsKKworCQkJCQlpZiAoKmxhc3Rwb3J0IDwgZmlyc3QgfHwg Kmxhc3Rwb3J0ID4gbGFzdCkKKwkJCQkJCSpsYXN0cG9ydCA9IGZpcnN0OworCQkJCQlscG9ydCA9 IGh0b25zKCpsYXN0cG9ydCk7CisJCQkJfSB3aGlsZSAoaW5fcGNibG9va3VwX2xvY2FsKHBjYmlu Zm8sIGxhZGRyLAorCQkJCSAgICBscG9ydCwgd2lsZCwgY3JlZCkpOworCisJCQkJYnJlYWs7CisJ CQljYXNlIDE6CQkvKiBTaW1wbGUgUG9ydCBSYW5kb21pemF0aW9uIEFsZ29yaXRobSBJICovCisJ CQlkZWZhdWx0OgorCQkJCSpsYXN0cG9ydCA9IGZpcnN0ICsgKGFyYzRyYW5kb20oKSAlIChsYXN0 IC0gZmlyc3QpKTsKKworCQkJCWRvIHsKKwkJCQkJaWYgKGNvdW50LS0gPCAwKQkvKiBjb21wbGV0 ZWx5IHVzZWQ/ICovCisJCQkJCQlyZXR1cm4gKEVBRERSTk9UQVZBSUwpOworCisJCQkJCSsrKmxh c3Rwb3J0OworCisJCQkJCWlmICgqbGFzdHBvcnQgPCBmaXJzdCB8fCAqbGFzdHBvcnQgPiBsYXN0 KQorCQkJCQkJKmxhc3Rwb3J0ID0gZmlyc3Q7CisJCQkJCWxwb3J0ID0gaHRvbnMoKmxhc3Rwb3J0 KTsKKwkJCQl9IHdoaWxlIChpbl9wY2Jsb29rdXBfbG9jYWwocGNiaW5mbywgbGFkZHIsCisJCQkJ ICAgIGxwb3J0LCB3aWxkLCBjcmVkKSk7CisJCQl9CisJCX0gZWxzZSB7CisJCQlkbyB7CisJCQkJ aWYgKGNvdW50LS0gPCAwKSAgICAgICAgLyogY29tcGxldGVseSB1c2VkPyAqLworCQkJCQlyZXR1 cm4gKEVBRERSTk9UQVZBSUwpOworCQorCQkJCSsrKmxhc3Rwb3J0OworCisJCQkJaWYgKCpsYXN0 cG9ydCA8IGZpcnN0IHx8ICpsYXN0cG9ydCA+IGxhc3QpCisJCQkJCSpsYXN0cG9ydCA9IGZpcnN0 OworCQkJCWxwb3J0ID0gaHRvbnMoKmxhc3Rwb3J0KTsKKwkJCX0gd2hpbGUgKGluX3BjYmxvb2t1 cF9sb2NhbChwY2JpbmZvLCBsYWRkciwKKwkJCSAgICBscG9ydCwgd2lsZCwgY3JlZCkpOworCQl9 CiAJfQogCSpsYWRkcnAgPSBsYWRkci5zX2FkZHI7CiAJKmxwb3J0cCA9IGxwb3J0OwpkaWZmIC1y IGZiZjEzMTMzNjJkNyBzcmMvc3lzL25ldGluZXQvaW5fcGNiLmgKLS0tIGEvc3JjL3N5cy9uZXRp bmV0L2luX3BjYi5oCVR1ZSBKYW4gMjUgMTQ6MDM6MzcgMjAxMSArMDIwMAorKysgYi9zcmMvc3lz L25ldGluZXQvaW5fcGNiLmgJV2VkIEphbiAyNiAxMjo1ODowNSAyMDExICswMjAwCkBAIC00NjYs NiArNDY2LDcgQEAKIFZORVRfREVDTEFSRShpbnQsIGlwcG9ydF9yYW5kb210aW1lKTsKIFZORVRf REVDTEFSRShpbnQsIGlwcG9ydF9zdG9wcmFuZG9tKTsKIFZORVRfREVDTEFSRShpbnQsIGlwcG9y dF90Y3BhbGxvY3MpOworVk5FVF9ERUNMQVJFKGludCwgaXBwb3J0X3JmYzYwNTZhbGcpOwogCiAj ZGVmaW5lCVZfaXBwb3J0X3Jlc2VydmVkaGlnaAlWTkVUKGlwcG9ydF9yZXNlcnZlZGhpZ2gpCiAj ZGVmaW5lCVZfaXBwb3J0X3Jlc2VydmVkbG93CVZORVQoaXBwb3J0X3Jlc2VydmVkbG93KQpAQCAt NDgwLDYgKzQ4MSw3IEBACiAjZGVmaW5lCVZfaXBwb3J0X3JhbmRvbXRpbWUJVk5FVChpcHBvcnRf cmFuZG9tdGltZSkKICNkZWZpbmUJVl9pcHBvcnRfc3RvcHJhbmRvbQlWTkVUKGlwcG9ydF9zdG9w cmFuZG9tKQogI2RlZmluZQlWX2lwcG9ydF90Y3BhbGxvY3MJVk5FVChpcHBvcnRfdGNwYWxsb2Nz KQorI2RlZmluZSBWX2lwcG9ydF9yZmM2MDU2YWxnCVZORVQoaXBwb3J0X3JmYzYwNTZhbGcpCiAK IGV4dGVybiBzdHJ1Y3QgY2FsbG91dCBpcHBvcnRfdGlja19jYWxsb3V0OwogCg== --0015175ce06ac62152049abe21a9-- From owner-freebsd-net@FreeBSD.ORG Wed Jan 26 13:07:44 2011 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 6B6F0106564A for ; Wed, 26 Jan 2011 13:07:44 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 3AE138FC18 for ; Wed, 26 Jan 2011 13:07:44 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id C399B46B09; Wed, 26 Jan 2011 08:07:43 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 1181A8A009; Wed, 26 Jan 2011 08:07:42 -0500 (EST) From: John Baldwin To: freebsd-net@freebsd.org Date: Wed, 26 Jan 2011 07:59:22 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.4-CBSD-20110107; KDE/4.4.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201101260759.22809.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 26 Jan 2011 08:07:42 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Ivo Vachkov Subject: Re: Proposed patch for Port Randomization modifications according to RFC6056 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, 26 Jan 2011 13:07:44 -0000 On Wednesday, January 26, 2011 6:28:07 am Ivo Vachkov wrote: > Hello, > > I would like to propose a patch (against FreeBSD RELENG_8) to extend > the port randomization support in FreeBSD, according to RFC6056 > (https://www.rfc-editor.org/rfc/rfc6056.txt) > > Currently the patch implements: > - Algorithm 1 (default in FreeBSD 8) > - Algorithm 2 > - Algorithm 5 > from the aforementioned RFC6056. > > Any of those algorithms can be chosen with the sysctl variable > net.inet.ip.portrange.rfc6056_algorithm. > > I deliberately skipped Algorithm 3 and Algorithm 4, because I believe > usage of cryptographic hash functions will introduce unnecessary > latency in vital network operations. However, in case of expressed > interest, I will be glad to add those too. > > I would like to ask what is the proper way to validate the sysctl > input in order to accept only a specific values? In my case only '1', > '2' and '5'. Use a SYSCTL_PROC and write your own handler that does a sanity check on the value set by userland and returns EINVAL if the value is not correct. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Wed Jan 26 13:30:07 2011 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 AC019106564A for ; Wed, 26 Jan 2011 13:30:07 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id 3B2B88FC0C for ; Wed, 26 Jan 2011 13:30:07 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 3CCF641C72F; Wed, 26 Jan 2011 14:30:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id pnehKq0Zzo3h; Wed, 26 Jan 2011 14:30:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id ACD0041C72C; Wed, 26 Jan 2011 14:30:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 4BF194448F3; Wed, 26 Jan 2011 13:27:04 +0000 (UTC) Date: Wed, 26 Jan 2011 13:27:03 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Ivo Vachkov In-Reply-To: Message-ID: <20110126132240.J3489@maildrop.int.zabbadoz.net> References: X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD Net Subject: Re: Proposed patch for Port Randomization modifications according to RFC6056 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, 26 Jan 2011 13:30:07 -0000 On Wed, 26 Jan 2011, Ivo Vachkov wrote: Hi, > I would like to propose a patch (against FreeBSD RELENG_8) to extend > the port randomization support in FreeBSD, according to RFC6056 > (https://www.rfc-editor.org/rfc/rfc6056.txt) > > Currently the patch implements: > - Algorithm 1 (default in FreeBSD 8) > - Algorithm 2 > - Algorithm 5 > from the aforementioned RFC6056. > > Any of those algorithms can be chosen with the sysctl variable > net.inet.ip.portrange.rfc6056_algorithm. > > I deliberately skipped Algorithm 3 and Algorithm 4, because I believe > usage of cryptographic hash functions will introduce unnecessary > latency in vital network operations. However, in case of expressed > interest, I will be glad to add those too. > > I would like to ask what is the proper way to validate the sysctl > input in order to accept only a specific values? In my case only '1', > '2' and '5'. > > Thank you very much. It needs to be implemented in sys/netinet6/in6_src.c as well. Given the growth I wonder if we can design it more intelligent to avoid more code duplication for 3 (to 5) alogrithms, especially considering, that syncing between legacy and ipv6 has failed in the past. /bz -- Bjoern A. Zeeb You have to have visions! Going to jail sucks -- All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html From owner-freebsd-net@FreeBSD.ORG Wed Jan 26 13:49:11 2011 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 B6D61106564A for ; Wed, 26 Jan 2011 13:49:11 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 70C1C8FC0C for ; Wed, 26 Jan 2011 13:49:11 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkYFAN+0P02DaFvO/2dsb2JhbACEEpJFjxKrQZBvgSODOHQEhReHEg X-IronPort-AV: E=Sophos;i="4.60,380,1291611600"; d="scan'208";a="106954848" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 26 Jan 2011 08:48:05 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 07B5FB3E95; Wed, 26 Jan 2011 08:48:05 -0500 (EST) Date: Wed, 26 Jan 2011 08:48:05 -0500 (EST) From: Rick Macklem To: sebastian.tymkow@gmail.com Message-ID: <1633260526.867669.1296049684977.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - IE8 (Win)/6.0.10_GA_2692) Cc: freebsd-net@freebsd.org Subject: re: pr 154255 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, 26 Jan 2011 13:49:11 -0000 Hi, I think you need the following patch (which will be in 8.2): http://people.freebsd.org/~rmacklem/krpc.patch If you try the patch, please let us know if it resolves your problem. rick From owner-freebsd-net@FreeBSD.ORG Thu Jan 27 00:05:54 2011 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 05A011065672 for ; Thu, 27 Jan 2011 00:05:54 +0000 (UTC) (envelope-from lists@rewt.org.uk) Received: from frankie.stf.rewt.org.uk (frankie.stf.rewt.org.uk [91.208.177.187]) by mx1.freebsd.org (Postfix) with ESMTP id B389C8FC14 for ; Thu, 27 Jan 2011 00:05:53 +0000 (UTC) Received: from [172.16.11.69] (jwh-laptop.barbary [172.16.11.69]) by frankie.stf.rewt.org.uk (Postfix) with ESMTPA id 325A45081E; Thu, 27 Jan 2011 00:05:45 +0000 (UTC) Message-ID: <4D40B6E1.2050506@rewt.org.uk> Date: Thu, 27 Jan 2011 00:05:53 +0000 From: Joe Holden User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Alexander Zagrebin References: <20110125133226.GD67220@gw.zagrebin.ru> <4D3EF966.7010209@gmx.com> <20110126052147.GF67220@gw.zagrebin.ru> In-Reply-To: <20110126052147.GF67220@gw.zagrebin.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Nikos Vassiliadis Subject: Re: 8.2-PRERELEASE: if_bridge ARP and broadcasts issues 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, 27 Jan 2011 00:05:54 -0000 On 26/01/2011 05:21, Alexander Zagrebin wrote: > Hi! > > On 25.01.2011 18:25:10 +0200, Nikos Vassiliadis wrote: > >>> The reason is in ARP handling code: it looks for an address of the interface >>> belonging to a bridge, but there is not check that a bridge is the same. >>> >>> Attached patch (patch-if_ether.c) fixes the issue. >>> >> >> I tried your patch and it works for me. > > Thanks for confirmation! > >> >>> 2. Broadcasts issue >>> >>> I have a box with two NICs: re0 and wlan0. re0 and wlan0 are members of the >>> bridge0. re0 has IP address 192.168.1.1; wlan0 hasn't an address configured. >>> I have the samba installed. The smbd and nmbd listens on the 192.168.1.1. >>> There are no problems with the clients connected to the re0, but the samba >>> clients connected to the wlan0 has problems with the network browsing and >>> domain logons. >>> I've found that nmbd doesn't receive udp broadcasts received on the wlan0, >>> though bridge0 successfully retransmits this broadcast out of re0. >>> I've looked in the sources, and it seems that in this case subnet broadcasts >>> have to be handled in ether_output(), but this doesn't work anyway... >>> >>> Can anybody help to fix this issue? >> >> As far as I recall, the recommended setup is to assign IP addresses to >> the bridge interface, not the member interfaces. Could you try this? > > Yes, when ip address is assigned to bridge0 or inbound interface > (wlan0 in this case) then there are no problems. > This may be used as workaround, but... > As there is no direct interdiction to use addresses bound to a member interfaces, > it seems it's a bug. > That is valid behaviour, that is how it should be done - other oses such as linux enforce this behaviour. Thanks, J From owner-freebsd-net@FreeBSD.ORG Thu Jan 27 06:46:54 2011 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 B472E106566C; Thu, 27 Jan 2011 06:46:54 +0000 (UTC) (envelope-from adrian@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8B5A38FC0C; Thu, 27 Jan 2011 06:46:54 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p0R6ksdY000513; Thu, 27 Jan 2011 06:46:54 GMT (envelope-from adrian@freefall.freebsd.org) Received: (from adrian@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p0R6kstN000509; Thu, 27 Jan 2011 06:46:54 GMT (envelope-from adrian) Date: Thu, 27 Jan 2011 06:46:54 GMT Message-Id: <201101270646.p0R6kstN000509@freefall.freebsd.org> To: adrian@FreeBSD.org, freebsd-net@FreeBSD.org, adrian@FreeBSD.org From: adrian@FreeBSD.org Cc: Subject: Re: kern/154237: [ath] AR9280 w/ AES-CCMP (WPA2) group key does not work 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, 27 Jan 2011 06:46:54 -0000 Synopsis: [ath] AR9280 w/ AES-CCMP (WPA2) group key does not work Responsible-Changed-From-To: freebsd-net->adrian Responsible-Changed-By: adrian Responsible-Changed-When: Thu Jan 27 06:46:47 UTC 2011 Responsible-Changed-Why: My bug http://www.freebsd.org/cgi/query-pr.cgi?pr=154237 From owner-freebsd-net@FreeBSD.ORG Thu Jan 27 07:51:17 2011 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 4D1E8106564A for ; Thu, 27 Jan 2011 07:51:17 +0000 (UTC) (envelope-from fernando.gont.netbook.win@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 F385E8FC17 for ; Thu, 27 Jan 2011 07:51:16 +0000 (UTC) Received: by ywp6 with SMTP id 6so509520ywp.13 for ; Wed, 26 Jan 2011 23:51:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=qMFpgrRSYO4QsRnJTx1vKaFfuKckYEVk+7VwARmg13k=; b=UiR4vqBxcAxvzJ0DQLJR0SxnERRsMJhdiVjAl0cxqN9WX0z0MHdBwkbfM+NePWpPuH hiYU5T6vtKUX55DKlXufVWQ5xeQtJrP9VFO/e5Z+jS58DVP22Tm7X1iQ/l70h3UTfSy/ 0sTuNL8EyefmnpxWRnFLknySqgruPYW4zpTWc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=kT9OKxtNSbp0vUZn8Hu6fTNy8waUmi+Cy4YPGtyzmP1DI99kns34ZEpMtJNWvNJ4dE PJ8QyyXLBRkUbXViiDcRthHsxw715JdJHNACOE29/G91s7Cfl63Dwyy6uZNY0nARzMd8 EkBqd4r4h1+fipTX4TYWWWW5ujTpFE+A/62p0= Received: by 10.91.26.24 with SMTP id d24mr2554785agj.160.1296112850404; Wed, 26 Jan 2011 23:20:50 -0800 (PST) Received: from [192.168.2.3] (122-172-17-190.fibertel.com.ar [190.17.172.122]) by mx.google.com with ESMTPS id w6sm260889anf.26.2011.01.26.23.20.45 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 26 Jan 2011 23:20:49 -0800 (PST) Sender: Fernando Gont Message-ID: <4D411CC6.1090202@gont.com.ar> Date: Thu, 27 Jan 2011 04:20:38 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Ivo Vachkov References: In-Reply-To: X-Enigmail-Version: 1.1.1 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: FreeBSD Net Subject: Re: Proposed patch for Port Randomization modifications according to RFC6056 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, 27 Jan 2011 07:51:17 -0000 On 26/01/2011 08:28 a.m., Ivo Vachkov wrote: > I would like to propose a patch (against FreeBSD RELENG_8) to extend > the port randomization support in FreeBSD, according to RFC6056 > (https://www.rfc-editor.org/rfc/rfc6056.txt) > > Currently the patch implements: > - Algorithm 1 (default in FreeBSD 8) > - Algorithm 2 > - Algorithm 5 > from the aforementioned RFC6056. > > Any of those algorithms can be chosen with the sysctl variable > net.inet.ip.portrange.rfc6056_algorithm. > > I deliberately skipped Algorithm 3 and Algorithm 4, because I believe > usage of cryptographic hash functions will introduce unnecessary > latency in vital network operations. However, in case of expressed > interest, I will be glad to add those too. While my opinion may be biased (I'm a co-author of the aforementioned RFC), I'd strongly argue in favor of the hash-based algorithms. At the point in which you have a high connection-establishment rate with a specific destination endpoint, you want to reuse the chances of collisions. (IIRC, this is why the FreeBSD code at some point disabled port randomization when connections were being established at a high rate). As a datapoint, Linux ships with Algorithm #4 enabled by default. Thanks! Best regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From owner-freebsd-net@FreeBSD.ORG Fri Jan 28 08:14:22 2011 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 D26CF106564A for ; Fri, 28 Jan 2011 08:14:22 +0000 (UTC) (envelope-from mike.barnardq@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9122F8FC16 for ; Fri, 28 Jan 2011 08:14:22 +0000 (UTC) Received: by gwj21 with SMTP id 21so1045019gwj.13 for ; Fri, 28 Jan 2011 00:14:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=+CVxeTuUuBB+eUYjS5Tctbv1aDVHELN9LUl797X1zFQ=; b=Js3/9GUEitrTQj701QQcmRDD4+3lnFOqhNregcKf0lhUfSmnI03gKO8hG3CUoUZe2p ZQ2EvouTi13+eAw5ZofgPF0pdj8pCHRyQ5P3XcHicDYkeBWH00YNp1/KyoguelXLyTBq Ve07SH7Rf0704Tl6rB3qQ/bLpx014JV1T3/Uk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=E1gBDoJJeZXo7dkX6L77Ja89hgswbxe0+CHTtDMoIWK9uckiTN5VhxUPuE+5fhEh4/ +3Q3aKwVP7jsM7jCAVxNYiQq0foCzfN4uzjVG0tAGqx0/B8eLXWyCsQclOC25Trspuiy kUMxpGDZ5oeOPomKNtXPCSCtSnMEc73LFjV44= MIME-Version: 1.0 Received: by 10.100.252.20 with SMTP id z20mr1320772anh.104.1296200590213; Thu, 27 Jan 2011 23:43:10 -0800 (PST) Received: by 10.100.134.12 with HTTP; Thu, 27 Jan 2011 23:43:10 -0800 (PST) Date: Fri, 28 Jan 2011 10:43:10 +0300 Message-ID: From: Mike Barnard To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: CARP Failover 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, 28 Jan 2011 08:14:23 -0000 Hi, I have two firewalls, FW1 and FW2. Each server has three interfaces, bce0, bce1 and bce2 and of course the carp interfaces. FW1: bce0: 41.xxx.yyy.244/29 bce1: 172.19.254.14/30 bce2: 41.xxx.yyy.252/29 carp0: 41.202.229.243 carp1: 41.202.229.251 FW2: bce0: 41.xxx.yyy.245/29 bce1: 172.19.254.15/30 bce2: 41.xxx.yyy.253/29 carp0: 41.202.229.243 carp1: 41.202.229.251 FW1 is connected to SW1 and FW2 is connected to SW2. Both SW1 and SW2 connected to the aggregating switch. I have configured CARP in failover mode and the interesting thing is both firewall carp interfaces come up as master: FW1: carp0: flags=49 metric 0 mtu 1500 inet 41.xxx.yyy.243 netmask 0xfffffff8 carp: MASTER vhid 1 advbase 1 advskew 1 carp1: flags=49 metric 0 mtu 1500 inet 41.xxx.yyy.251 netmask 0xfffffff8 carp: MASTER vhid 2 advbase 1 advskew 1 FW2: carp0: flags=49 metric 0 mtu 1500 inet 41.xxx.yyy.243 netmask 0xfffffff8 carp: MASTER vhid 1 advbase 1 advskew 100 carp1: flags=49 metric 0 mtu 1500 inet 41.xxx.yyy.251 netmask 0xfffffff8 carp: MASTER vhid 2 advbase 1 advskew 100 The pfsync0 interfaces on both are configured thus: FW1: pfsync0: flags=41 metric 0 mtu 1460 pfsync: syncdev: bce1 syncpeer: 172.19.254.15 maxupd: 128 FW2: pfsync0: flags=41 metric 0 mtu 1460 pfsync: syncdev: bce1 syncpeer: 172.19.254.14 maxupd: 128 my sysctl variables on both firewalls are set thus: net.inet.carp.allow=1 # Allow the firewall to accept CARP packets net.inet.carp.preempt=1 # Allow firewalls to failover when one goes down net.inet.ip.forwarding=1 # Allow packet forwarding through the firewalls Am I missing something, mis-configured something or somehow missed something out? Thanks. -- Mike Of course, you might discount this possibility, but remember that one in a million chances happen 99% of the time. ------------------------------------------------------------ From owner-freebsd-net@FreeBSD.ORG Fri Jan 28 09:00:20 2011 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 C355A1065674; Fri, 28 Jan 2011 09:00:20 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 50D708FC12; Fri, 28 Jan 2011 09:00:19 +0000 (UTC) Received: by qyk36 with SMTP id 36so2997319qyk.13 for ; Fri, 28 Jan 2011 01:00:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:date:x-google-sender-auth :message-id:subject:from:to:cc:content-type; bh=Sb9W0r88/pq3iv9JalGoidy+KMarTLaG5RhlJpHOZZY=; b=Y0ykoDwm7aia/YaQ3hkdczzyF/otGPHMbXzxWGRMxINljHDSpEYfDZjJfuU+1qrvfG z+yMLrZnlFNnxuKL5c9vio5ng8S0fn2fFysCKWo8RdTdZ3p73HKJkEUC2lcOdk0ruoKV GhpbDOVXwRDtdEiay+lhV/7g03dcP8jGlffgw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; b=L3eQEUmlArAYwQU7lTavhvI3M1kg83X8u1kYpSbxDcujeuxnSHq4fGPYaHusKmr+ei Nat+/xVgPxm7ALbbHPLViGrqsxFgIeN7mHL/jVvxjkEjoDifuQoL9NtTEsmyzZySs/ta KsmnMfJpSBf1ZnOALpgVjIUI3eJYHn5jZj7iM= MIME-Version: 1.0 Received: by 10.224.19.203 with SMTP id c11mr2744244qab.170.1296205219207; Fri, 28 Jan 2011 01:00:19 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.220.198.203 with HTTP; Fri, 28 Jan 2011 01:00:19 -0800 (PST) Date: Fri, 28 Jan 2011 17:00:19 +0800 X-Google-Sender-Auth: RxWpdUXLT1nI00-e8GUiEjQ9QZ0 Message-ID: From: Adrian Chadd To: freebsd-mobile@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Net , freebsd-current Subject: [ath] ath_rate_sample changes; please test 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, 28 Jan 2011 09:00:20 -0000 Hi, I've just committed some changes to the ath_rate_sample module which teach it the bare minimum to transmit MCS frames when in 11n mode. No, this doesn't mean 11n mode is yet available or ready (there's some further work in the TX path first.) I'd appreciate some testing of this just to ensure I haven't busted legacy mode. Thanks, Adrian From owner-freebsd-net@FreeBSD.ORG Fri Jan 28 14:34:16 2011 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 8048B106566B for ; Fri, 28 Jan 2011 14:34:16 +0000 (UTC) (envelope-from ivo.vachkov@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 35C658FC0A for ; Fri, 28 Jan 2011 14:34:15 +0000 (UTC) Received: by qyk36 with SMTP id 36so3285769qyk.13 for ; Fri, 28 Jan 2011 06:34:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Zwh47L9UbNsLkZ6mPfT3bIUYubB0fIadtlONle0o0iY=; b=aF5j79fzhu5TiHKc7pSdZzdTC4lRB1CdDj8ye0LKHu39vsC19LC731zTJ8dSg3vhI4 j68pq1oSgimNuIsCZrLI436Xww1z6w5fmJ2qb5wy6IK3gQetOBhuTS3w9Q9eewyITxRj wGgKFDDsqTP+ZMOtb2ZhNax6KvHKbvGkOxeKQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=q4t2fkgV0XGMLfznCfAIk4Bwi/HxE1eOyGljkKlF5pltZLl7FPiMPo3t5j66vqY+zM Y3WD69/I87/8L0MMLYL9FsxN3qiu1locz1N92yY70WNxFBV6EDHsHSsmcDQFJbQUE6yS L2o1aD+yuIV7HVAvbbAtwTuIf0I4HAsSQKpcc= Received: by 10.224.73.129 with SMTP id q1mr3067559qaj.112.1296225255301; Fri, 28 Jan 2011 06:34:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.193.9 with HTTP; Fri, 28 Jan 2011 06:33:55 -0800 (PST) In-Reply-To: <4D411CC6.1090202@gont.com.ar> References: <4D411CC6.1090202@gont.com.ar> From: Ivo Vachkov Date: Fri, 28 Jan 2011 16:33:55 +0200 Message-ID: To: FreeBSD Net Content-Type: multipart/mixed; boundary=0015175cb99ae421ce049ae8f559 Cc: bz@freebsd.org Subject: Re: Proposed patch for Port Randomization modifications according to RFC6056 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, 28 Jan 2011 14:34:16 -0000 --0015175cb99ae421ce049ae8f559 Content-Type: text/plain; charset=UTF-8 Hello, I would like to thank for the help and for the recommendations. I attach second version of the patch, I proposed earlier, including following changes: 1) All RFC6056 algorithms are implemented. 2) Both IPv4 and IPv6 stacks are modified to use the new port randomization code. 3) There are two variables that can be modified via sysctl: - net.inet.ip.portrange.rfc6056_algorithm - which allows the super user to choose one out of the five possible algorithms. - net.inet.ip.portrange.rfc6056_algorithm5_tradeoff - which allows the super user to modify the trade-off value used in algorithm 5. All values are explicitly checked for correctness before usage. Default values for those variables represent current/legacy port randomization algorithm and proposed values in the RFC itself. Thank you very much. Ivo Vachkov --0015175cb99ae421ce049ae8f559 Content-Type: text/x-patch; charset=US-ASCII; name="20110128-freebsd-RELENG_8-rfc6056.patch" Content-Disposition: attachment; filename="20110128-freebsd-RELENG_8-rfc6056.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gjh6hwl60 ZGlmZiAtciA0ZWEwNzdmNTQ2ZGQgc3JjL3N5cy9uZXRpbmV0L2luX3BjYi5jCi0tLSBhL3NyYy9z eXMvbmV0aW5ldC9pbl9wY2IuYwlGcmkgSmFuIDI4IDEyOjIxOjA4IDIwMTEgKzAyMDAKKysrIGIv c3JjL3N5cy9uZXRpbmV0L2luX3BjYi5jCUZyaSBKYW4gMjggMTY6MTA6MDggMjAxMSArMDIwMApA QCAtODEsNiArODEsOCBAQAogI2luY2x1ZGUgPG5ldGlwc2VjL2tleS5oPgogI2VuZGlmIC8qIElQ U0VDICovCiAKKyNpbmNsdWRlIDxzeXMvbWQ1Lmg+CQorCiAjaW5jbHVkZSA8c2VjdXJpdHkvbWFj L21hY19mcmFtZXdvcmsuaD4KIAogLyoKQEAgLTEwOSw2ICsxMTEsOCBAQAogVk5FVF9ERUZJTkUo aW50LCBpcHBvcnRfc3RvcHJhbmRvbSk7CQkvKiB0b2dnbGVkIGJ5IGlwcG9ydF90aWNrICovCiBW TkVUX0RFRklORShpbnQsIGlwcG9ydF90Y3BhbGxvY3MpOwogc3RhdGljIFZORVRfREVGSU5FKGlu dCwgaXBwb3J0X3RjcGxhc3Rjb3VudCk7CitWTkVUX0RFRklORSh1X2ludCwgaXBwb3J0X3JmYzYw NTZhbGcpID0gMTsJLyogdXNlciBjb250cm9sbGVkIHZpYSBzeXNjdGwgKi8KK1ZORVRfREVGSU5F KHVfaW50LCBpcHBvcnRfcmZjNjA1NmFsZzVfdHJhZGVvZmYpID0gNTAwOwkvKiB1c2VyIGNvbnRy b2xsZWQgdmlhIHN5c2N0bCAqLwogCiAjZGVmaW5lCVZfaXBwb3J0X3RjcGxhc3Rjb3VudAkJVk5F VChpcHBvcnRfdGNwbGFzdGNvdW50KQogCkBAIC0xNDEsNiArMTQ1LDY1IEBACiAKICN1bmRlZiBS QU5HRUNISwogCisvKgorICogVXBkYXRlcyBWX2lwcG9ydF9yZmM2MDU2YWxnIHRvIHRoZSBwcm92 aWRlZCB2YWx1ZSBhbmQKKyAqIGVuc3VyZXMgaXQgaXMgaW4gdGhlIHN1cHBvcnRlZCByYW5nZSAo MSAtIDUpCisgKi8KK3N0YXRpYyBpbnQKK3N5c2N0bF9uZXRfcmZjNjA1Nl9hbGdvcml0aG1fY2hl Y2soU1lTQ1RMX0hBTkRMRVJfQVJHUykKK3sKKwl1X2ludCBhbGdvcml0aG0gPSAqKHVfaW50ICop YXJnMTsKKwlpbnQgZXJyb3I7CisKKyNpZmRlZiBWSU1BR0UKKwllcnJvciA9IHZuZXRfc3lzY3Rs X2hhbmRsZV91aW50KG9pZHAsICZhbGdvcml0aG0sIDAsIHJlcSk7CisjZWxzZQorCWVycm9yID0g c3lzY3RsX2hhbmRsZV9pbnQob2lkcCwgJmFsZ29yaXRobSwgMCwgcmVxKTsKKyNlbmRpZgorCisJ aWYgKGVycm9yID09IDApIHsKKwkJc3dpdGNoIChhbGdvcml0aG0pIHsKKwkJY2FzZSBJTlBfUkZD NjA1Nl9BTEdfMToKKwkJY2FzZSBJTlBfUkZDNjA1Nl9BTEdfMjoKKwkJY2FzZSBJTlBfUkZDNjA1 Nl9BTEdfMzoKKwkJY2FzZSBJTlBfUkZDNjA1Nl9BTEdfNDoKKwkJY2FzZSBJTlBfUkZDNjA1Nl9B TEdfNToKKwkJCVZfaXBwb3J0X3JmYzYwNTZhbGcgPSBhbGdvcml0aG07CisJCQlicmVhazsKKwkJ ZGVmYXVsdDoKKwkJCXJldHVybiAoRUlOVkFMKTsKKwkJfQorCX0gCQorCisJcmV0dXJuIChlcnJv cik7Cit9CisKKy8qCisgKiBVcGRhdGVzIFZfaXBwb3J0X3JmYzYwNTZhbGc1X3RyYWRlb2ZmIHRv IHByb3ZpZGVkIHZhbHVlCisgKiBhbmQgZW5zdXJlcyBpdCBpcyBpbiB0aGUgc3VwcG9ydGVkIHJh bmdlICgxIC0gNjU1MzYpCisgKi8KK3N0YXRpYyBpbnQKK3N5c2N0bF9uZXRfcmZjNjA1NmFsZzVf dHJhZGVvZmZfY2hlY2soU1lTQ1RMX0hBTkRMRVJfQVJHUykKK3sKKwl1X2ludCB0cmFkZW9mZiA9 ICoodV9pbnQgKilhcmcxOworCWludCBlcnJvcjsKKworI2lmZGVmIFZJTUFHRQorCWVycm9yID0g dm5ldF9zeXNjdGxfaGFuZGxlX3VpbnQob2lkcCwgJnRyYWRlb2ZmLCAwLCByZXEpOworI2Vsc2UK KwllcnJvciA9IHN5c2N0bF9oYW5kbGVfaW50KG9pZHAsICZ0cmFkZW9mZiwgMCwgcmVxKTsKKyNl bmRpZgorCisJaWYgKGVycm9yID09IDApIHsKKwkJaWYgKHRyYWRlb2ZmIDwgMSB8fCB0cmFkZW9m ZiA+IDY1NTM2KQorCQkJcmV0dXJuIChFSU5WQUwpOworCQllbHNlCisJCQlWX2lwcG9ydF9yZmM2 MDU2YWxnNV90cmFkZW9mZiA9IHRyYWRlb2ZmOworCX0KKworCXJldHVybiAoZXJyb3IpOworfQor CiBTWVNDVExfTk9ERShfbmV0X2luZXRfaXAsIElQUFJPVE9fSVAsIHBvcnRyYW5nZSwgQ1RMRkxB R19SVywgMCwgIklQIFBvcnRzIik7CiAKIFNZU0NUTF9WTkVUX1BST0MoX25ldF9pbmV0X2lwX3Bv cnRyYW5nZSwgT0lEX0FVVE8sIGxvd2ZpcnN0LApAQCAtMTc0LDYgKzIzNywxNSBAQAogCSZWTkVU X05BTUUoaXBwb3J0X3JhbmRvbXRpbWUpLCAwLAogCSJNaW5pbXVtIHRpbWUgdG8ga2VlcCBzZXF1 ZW50YWwgcG9ydCAiCiAJImFsbG9jYXRpb24gYmVmb3JlIHN3aXRjaGluZyB0byBhIHJhbmRvbSBv bmUiKTsKK1NZU0NUTF9WTkVUX1BST0MoX25ldF9pbmV0X2lwX3BvcnRyYW5nZSwgT0lEX0FVVE8s IHJmYzYwNTZfYWxnb3JpdGhtLAorCUNUTFRZUEVfVUlOVHxDVExGTEFHX1JXLCAmVk5FVF9OQU1F KGlwcG9ydF9yZmM2MDU2YWxnKSwgMCwKKwkmc3lzY3RsX25ldF9yZmM2MDU2X2FsZ29yaXRobV9j aGVjaywgIklVIiwgCisJIlJGQyA2MDU2IFBvcnQgcmFuZG9taXphdGlvbiBhbGdvcml0aG0iKTsK K1NZU0NUTF9WTkVUX1BST0MoX25ldF9pbmV0X2lwX3BvcnRyYW5nZSwgT0lEX0FVVE8sCisJcmZj NjA1Nl9hbGdvcml0aG01X3RyYWRlb2ZmLCBDVExUWVBFX1VJTlR8Q1RMRkxBR19SVywKKwkmVk5F VF9OQU1FKGlwcG9ydF9yZmM2MDU2YWxnNV90cmFkZW9mZiksIDAsCisJJnN5c2N0bF9uZXRfcmZj NjA1NmFsZzVfdHJhZGVvZmZfY2hlY2ssICJJVSIsCisJIlJGQyA2MDU2IEFsZ29yaXRobSA1IGNv bXB1dGF0aW9uYWwgdHJhZGUtb2ZmIik7CiAKIC8qCiAgKiBpbl9wY2IuYzogbWFuYWdlIHRoZSBQ cm90b2NvbCBDb250cm9sIEJsb2Nrcy4KQEAgLTQ2OCwyMSArNTQwLDE3NyBAQAogCQkJbGFzdCA9 IGF1eDsKIAkJfQogCi0JCWlmIChkb3JhbmRvbSkKLQkJCSpsYXN0cG9ydCA9IGZpcnN0ICsKLQkJ CQkgICAgKGFyYzRyYW5kb20oKSAlIChsYXN0IC0gZmlyc3QpKTsKLQogCQljb3VudCA9IGxhc3Qg LSBmaXJzdDsKIAotCQlkbyB7Ci0JCQlpZiAoY291bnQtLSA8IDApCS8qIGNvbXBsZXRlbHkgdXNl ZD8gKi8KLQkJCQlyZXR1cm4gKEVBRERSTk9UQVZBSUwpOwotCQkJKysqbGFzdHBvcnQ7Ci0JCQlp ZiAoKmxhc3Rwb3J0IDwgZmlyc3QgfHwgKmxhc3Rwb3J0ID4gbGFzdCkKLQkJCQkqbGFzdHBvcnQg PSBmaXJzdDsKLQkJCWxwb3J0ID0gaHRvbnMoKmxhc3Rwb3J0KTsKLQkJfSB3aGlsZSAoaW5fcGNi bG9va3VwX2xvY2FsKHBjYmluZm8sIGxhZGRyLAotCQkgICAgbHBvcnQsIHdpbGQsIGNyZWQpKTsK KwkJLyogCisJCSAqIEFjY29yZGluZyB0byBSRkM2MDU2IHRoZXJlIGFyZSA1IChmaXZlKSBwb3Nz aWJsZSBhbGdvcml0aG1zCisJCSAqIGZvciByYW5kb20gcG9ydCBhbGxvY2F0aW9uLiBVc2FnZSBv ZiBhIHBhcnRpY3VsYXIgYWxnb3JpdGhtCisJCSAqIGlzIHNwZWNpZmllZCB3aXRoIHRoZSAnbmV0 LmluZXQuaXAucG9ydHJhbmdlLnJmYzYwNTZfYWxnb3JpdGhtJworCQkgKiBzeXNjdGwgdmFyaWFi bGUuIERlZmF1bHQgdmFsdWUgaXMgMSwgd2hpY2ggcmVwcmVzZW50cyB0aGUKKwkJICogbGVnYWN5 IHJhbmRvbSBwb3J0IGFsbG9jYXRpb24gYWxnb3JpdGhtIGluIEZyZWVCU0QuCisJCSAqLworCQlp ZiAoZG9yYW5kb20pIHsKKwkJCXN3aXRjaCAoVl9pcHBvcnRfcmZjNjA1NmFsZykgeworCQkJY2Fz ZSBJTlBfUkZDNjA1Nl9BTEdfNToJLyogUmFuZG9tLUluY3JlbWVudHMgUG9ydCBTZWxlY3Rpb24g Ki8KKwkJCQlkbyB7CisJCQkJCWlmIChjb3VudC0tIDwgMCkJLyogY29tcGxldGVseSB1c2VkPyAq LworCQkJCQkJcmV0dXJuIChFQUREUk5PVEFWQUlMKTsKKworCQkJCQkqbGFzdHBvcnQgPSBmaXJz dCArICgoYXJjNHJhbmRvbSgpICUgNjU1MzYpICsgCisJCQkJCSAgICAoYXJjNHJhbmRvbSgpICUg Vl9pcHBvcnRfcmZjNjA1NmFsZzVfdHJhZGVvZmYpICsgMSk7CisKKwkJCQkJaWYgKCpsYXN0cG9y dCA8IGZpcnN0IHx8ICpsYXN0cG9ydCA+IGxhc3QpCisJCQkJCQkqbGFzdHBvcnQgPSBmaXJzdDsK KwkJCQkJbHBvcnQgPSBodG9ucygqbGFzdHBvcnQpOworCQkJCX0gd2hpbGUgKGluX3BjYmxvb2t1 cF9sb2NhbChwY2JpbmZvLCBsYWRkciwKKwkJCQkgICAgbHBvcnQsIHdpbGQsIGNyZWQpKTsKKwkJ CQlicmVhazsKKwkJCWNhc2UgSU5QX1JGQzYwNTZfQUxHXzQ6CS8qIERvdWJsZS1IYXNoIFBvcnQg U2VsZWN0aW9uIEFsZ29yaXRobSAqLworCQkJCXsKKwkJCQkJTUQ1X0NUWCBmX2N0eDsKKwkJCQkJ TUQ1X0NUWCBnX2N0eDsKKwkJCQkJdV9pbnQzMl90IEZbNF0gPSB7IDAsIDAsIDAsIDAgfTsKKwkJ CQkJdV9pbnQzMl90IEdbNF0gPSB7IDAsIDAsIDAsIDAgfTsKKwkJCQkJdV9pbnQzMl90IHNlY3Jl dF9mWzRdID0geyAwLCAwLCAwLCAwIH07CisJCQkJCXVfaW50MzJfdCBzZWNyZXRfZ1s0XSA9IHsg MCwgMCwgMCwgMCB9OworCQkJCQl1X2ludDE2X3QgdGFibGVbMTZdOyAKKwkJCQkJdV9pbnQzMl90 IGluZGV4ID0gMDsKKwkJCQkJdV9pbnQzMl90IG9mZnNldCA9IDA7CisKKwkJCQkJc2VjcmV0X2Zb MF0gPSBhcmM0cmFuZG9tKCk7CisJCQkJCXNlY3JldF9mWzFdID0gYXJjNHJhbmRvbSgpOworCQkJ CQlzZWNyZXRfZlsyXSA9IGFyYzRyYW5kb20oKTsKKwkJCQkJc2VjcmV0X2ZbM10gPSBhcmM0cmFu ZG9tKCk7CisKKwkJCQkJc2VjcmV0X2dbMF0gPSBhcmM0cmFuZG9tKCk7CisJCQkJCXNlY3JldF9n WzFdID0gYXJjNHJhbmRvbSgpOworCQkJCQlzZWNyZXRfZ1syXSA9IGFyYzRyYW5kb20oKTsKKwkJ CQkJc2VjcmV0X2dbM10gPSBhcmM0cmFuZG9tKCk7CisKKwkJCQkJZm9yIChpbmRleCA9IDA7IGlu ZGV4IDwgc2l6ZW9mKHRhYmxlKTsgaW5kZXgrKykKKwkJCQkJCXRhYmxlW2luZGV4XSA9IGFyYzRy YW5kb20oKSAlIDY1NTM2OworCisJCQkJCU1ENUluaXQoJmZfY3R4KTsKKwkJCQkJTUQ1VXBkYXRl KCZmX2N0eCwgKHVfY2hhciAqKSZpbnAtPmlucF9sYWRkciwKKwkJCQkJICAgIHNpemVvZihpbnAt PmlucF9sYWRkcikpOworCQkJCQlNRDVVcGRhdGUoJmZfY3R4LCAodV9jaGFyICopJmlucC0+aW5w X2ZhZGRyLAorCQkJCQkgICAgc2l6ZW9mKGlucC0+aW5wX2ZhZGRyKSk7CisJCQkJCU1ENVVwZGF0 ZSgmZl9jdHgsICh1X2NoYXIgKikmaW5wLT5pbnBfZnBvcnQsCisJCQkJCSAgICBzaXplb2YoaW5w LT5pbnBfZnBvcnQpKTsKKwkJCQkJTUQ1VXBkYXRlKCZmX2N0eCwgKHVfY2hhciAqKXNlY3JldF9m LAorCQkJCQkgICAgc2l6ZW9mKHNlY3JldF9mKSk7CisJCQkJCU1ENUZpbmFsKCh1X2NoYXIgKikm RiwgJmZfY3R4KTsKKworCQkJCQlvZmZzZXQgPSAoKEZbMF0gXiBGWzFdKSBeIChGWzJdIF4gRlsz XSkpOworCisJCQkJCU1ENUluaXQoJmdfY3R4KTsKKwkJCQkJTUQ1VXBkYXRlKCZnX2N0eCwgKHVf Y2hhciAqKSZpbnAtPmlucF9sYWRkciwKKwkJCQkJICAgIHNpemVvZihpbnAtPmlucF9sYWRkcikp OworCQkJCQlNRDVVcGRhdGUoJmdfY3R4LCAodV9jaGFyICopJmlucC0+aW5wX2ZhZGRyLAorCQkJ CQkgICAgc2l6ZW9mKGlucC0+aW5wX2ZhZGRyKSk7CisJCQkJCU1ENVVwZGF0ZSgmZ19jdHgsICh1 X2NoYXIgKikmaW5wLT5pbnBfZnBvcnQsCisJCQkJCSAgICBzaXplb2YoaW5wLT5pbnBfZnBvcnQp KTsKKwkJCQkJTUQ1VXBkYXRlKCZnX2N0eCwgKHVfY2hhciAqKXNlY3JldF9nLAorCQkJCQkgICAg c2l6ZW9mKHNlY3JldF9nKSk7CisJCQkJCU1ENUZpbmFsKCh1X2NoYXIgKikmRywgJmdfY3R4KTsK KworCQkJCQlpbmRleCA9ICgoR1swXSBeIEdbMV0pIF4gKEdbMl0gXiBHWzNdKSkgJSBzaXplb2Yo dGFibGUpOworCisJCQkJCWRvIHsKKwkJCQkJCWlmIChjb3VudC0tIDwgMCkJLyogY29tcGxldGVs eSB1c2VkPyAqLworCQkJCQkJCXJldHVybiAoRUFERFJOT1RBVkFJTCk7CisKKwkJCQkJCSpsYXN0 cG9ydCA9IGZpcnN0ICsgCisJCQkJCQkgICAgKG9mZnNldCArIHRhYmxlW2luZGV4XSsrKSAlIGNv dW50OworCisJCQkJCQlpZiAoKmxhc3Rwb3J0IDwgZmlyc3QgfHwgKmxhc3Rwb3J0ID4gbGFzdCkK KwkJCQkJCQkqbGFzdHBvcnQgPSBmaXJzdDsKKwkJCQkJCWxwb3J0ID0gaHRvbnMoKmxhc3Rwb3J0 KTsKKwkJCQkJfSB3aGlsZSAoaW5fcGNibG9va3VwX2xvY2FsKHBjYmluZm8sIGxhZGRyLAorCQkJ CQkgICAgbHBvcnQsIHdpbGQsIGNyZWQpKTsKKwkJCQl9CisJCQkJYnJlYWs7CisJCQljYXNlIElO UF9SRkM2MDU2X0FMR18zOgkvKiBTaW1wbGUgSGFzaC1CYXNlZCBQb3J0IFNlbGVjdGlvbiBBbGdv cml0aG0gKi8KKwkJCQl7CisJCQkJCU1ENV9DVFggZl9jdHg7CisJCQkJCXVfaW50MzJfdCBGWzRd ID0geyAwLCAwLCAwLCAwIH07CisJCQkJCXVfaW50MzJfdCBzZWNyZXRfZls0XSA9IHsgMCwgMCwg MCwgMCB9OworCQkJCQl1X2ludDMyX3Qgb2Zmc2V0ID0gMDsKKworCQkJCQlzZWNyZXRfZlswXSA9 IGFyYzRyYW5kb20oKTsKKwkJCQkJc2VjcmV0X2ZbMV0gPSBhcmM0cmFuZG9tKCk7CisJCQkJCXNl Y3JldF9mWzJdID0gYXJjNHJhbmRvbSgpOworCQkJCQlzZWNyZXRfZlszXSA9IGFyYzRyYW5kb20o KTsKKworCQkJCQlNRDVJbml0KCZmX2N0eCk7CisJCQkJCU1ENVVwZGF0ZSgmZl9jdHgsICh1X2No YXIgKikmaW5wLT5pbnBfbGFkZHIsCisJCQkJCSAgICBzaXplb2YoaW5wLT5pbnBfbGFkZHIpKTsK KwkJCQkJTUQ1VXBkYXRlKCZmX2N0eCwgKHVfY2hhciAqKSZpbnAtPmlucF9mYWRkciwKKwkJCQkJ ICAgIHNpemVvZihpbnAtPmlucF9mYWRkcikpOworCQkJCQlNRDVVcGRhdGUoJmZfY3R4LCAodV9j aGFyICopJmlucC0+aW5wX2Zwb3J0LAorCQkJCQkgICAgc2l6ZW9mKGlucC0+aW5wX2Zwb3J0KSk7 CisJCQkJCU1ENVVwZGF0ZSgmZl9jdHgsICh1X2NoYXIgKilzZWNyZXRfZiwKKwkJCQkJICAgIHNp emVvZihzZWNyZXRfZikpOworCQkJCQlNRDVGaW5hbCgodV9jaGFyICopJkYsICZmX2N0eCk7CisK KwkJCQkJb2Zmc2V0ID0gKChGWzBdIF4gRlsxXSkgXiAoRlsyXSBeIEZbM10pKTsKKworCQkJCQlk byB7CisJCQkJCQlpZiAoY291bnQtLSA8IDApCS8qIGNvbXBsZXRlbHkgdXNlZD8gKi8KKwkJCQkJ CQlyZXR1cm4gKEVBRERSTk9UQVZBSUwpOworCisJCQkJCQkqbGFzdHBvcnQgPSBmaXJzdCArICgo YXJjNHJhbmRvbSgpICUgNjU1MzYpICsgCisJCQkJCQkgICAgKG9mZnNldCAlIDY1NTM2KSkgJSBj b3VudDsKKworCQkJCQkJaWYgKCpsYXN0cG9ydCA8IGZpcnN0IHx8ICpsYXN0cG9ydCA+IGxhc3Qp CisJCQkJCQkJKmxhc3Rwb3J0ID0gZmlyc3Q7CisJCQkJCQlscG9ydCA9IGh0b25zKCpsYXN0cG9y dCk7CisJCQkJCX0gd2hpbGUgKGluX3BjYmxvb2t1cF9sb2NhbChwY2JpbmZvLCBsYWRkciwKKwkJ CQkJICAgIGxwb3J0LCB3aWxkLCBjcmVkKSk7CQkJCQorCQkJCX0KKwkJCQlicmVhazsKKwkJCWNh c2UgSU5QX1JGQzYwNTZfQUxHXzI6CS8qIFNpbXBsZSBQb3J0IFJhbmRvbWl6YXRpb24gQWxnb3Jp dGhtIElJICovCisJCQkJZG8geworCQkJCQlpZiAoY291bnQtLSA8IDApCS8qIGNvbXBsZXRlbHkg dXNlZD8gKi8KKwkJCQkJCXJldHVybiAoRUFERFJOT1RBVkFJTCk7CisKKwkJCQkJKmxhc3Rwb3J0 ID0gZmlyc3QgKyAoYXJjNHJhbmRvbSgpICUgKGxhc3QgLSBmaXJzdCkpOworCisJCQkJCWlmICgq bGFzdHBvcnQgPCBmaXJzdCB8fCAqbGFzdHBvcnQgPiBsYXN0KQorCQkJCQkJKmxhc3Rwb3J0ID0g Zmlyc3Q7CisJCQkJCWxwb3J0ID0gaHRvbnMoKmxhc3Rwb3J0KTsKKwkJCQl9IHdoaWxlIChpbl9w Y2Jsb29rdXBfbG9jYWwocGNiaW5mbywgbGFkZHIsCisJCQkJICAgIGxwb3J0LCB3aWxkLCBjcmVk KSk7CisJCQkJYnJlYWs7CisJCQljYXNlIElOUF9SRkM2MDU2X0FMR18xOgkvKiBTaW1wbGUgUG9y dCBSYW5kb21pemF0aW9uIEFsZ29yaXRobSBJICovCisJCQlkZWZhdWx0OgorCQkJCSpsYXN0cG9y dCA9IGZpcnN0ICsgKGFyYzRyYW5kb20oKSAlIChsYXN0IC0gZmlyc3QpKTsKKworCQkJCWRvIHsK KwkJCQkJaWYgKGNvdW50LS0gPCAwKQkvKiBjb21wbGV0ZWx5IHVzZWQ/ICovCisJCQkJCQlyZXR1 cm4gKEVBRERSTk9UQVZBSUwpOworCisJCQkJCSsrKmxhc3Rwb3J0OworCisJCQkJCWlmICgqbGFz dHBvcnQgPCBmaXJzdCB8fCAqbGFzdHBvcnQgPiBsYXN0KQorCQkJCQkJKmxhc3Rwb3J0ID0gZmly c3Q7CisJCQkJCWxwb3J0ID0gaHRvbnMoKmxhc3Rwb3J0KTsKKwkJCQl9IHdoaWxlIChpbl9wY2Js b29rdXBfbG9jYWwocGNiaW5mbywgbGFkZHIsCisJCQkJICAgIGxwb3J0LCB3aWxkLCBjcmVkKSk7 CisJCQl9CisJCX0gZWxzZSB7CisJCQlkbyB7CisJCQkJaWYgKGNvdW50LS0gPCAwKSAgICAgICAg LyogY29tcGxldGVseSB1c2VkPyAqLworCQkJCQlyZXR1cm4gKEVBRERSTk9UQVZBSUwpOworCQor CQkJCSsrKmxhc3Rwb3J0OworCisJCQkJaWYgKCpsYXN0cG9ydCA8IGZpcnN0IHx8ICpsYXN0cG9y dCA+IGxhc3QpCisJCQkJCSpsYXN0cG9ydCA9IGZpcnN0OworCQkJCWxwb3J0ID0gaHRvbnMoKmxh c3Rwb3J0KTsKKwkJCX0gd2hpbGUgKGluX3BjYmxvb2t1cF9sb2NhbChwY2JpbmZvLCBsYWRkciwK KwkJCSAgICBscG9ydCwgd2lsZCwgY3JlZCkpOworCQl9CiAJfQogCSpsYWRkcnAgPSBsYWRkci5z X2FkZHI7CiAJKmxwb3J0cCA9IGxwb3J0OwpkaWZmIC1yIDRlYTA3N2Y1NDZkZCBzcmMvc3lzL25l dGluZXQvaW5fcGNiLmgKLS0tIGEvc3JjL3N5cy9uZXRpbmV0L2luX3BjYi5oCUZyaSBKYW4gMjgg MTI6MjE6MDggMjAxMSArMDIwMAorKysgYi9zcmMvc3lzL25ldGluZXQvaW5fcGNiLmgJRnJpIEph biAyOCAxNjoxMDowOCAyMDExICswMjAwCkBAIC00NTIsNiArNDUyLDE1IEBACiAKICNkZWZpbmUJ SU5QX0NIRUNLX1NPQ0tBRihzbywgYWYpCShJTlBfU09DS0FGKHNvKSA9PSBhZikKIAorLyoKKyAq IFJGQzYwNTYgUG9ydCBSYW5kb21pemF0aW9uIEFsZ29yaXRobXMKKyAqLworI2RlZmluZQlJTlBf UkZDNjA1Nl9BTEdfMQkxCS8qIFNpbXBsZSBQb3J0IFJhbmRvbWl6YXRpb24gQWxnb3JpdGhtIEkg Ki8KKyNkZWZpbmUJSU5QX1JGQzYwNTZfQUxHXzIJMgkvKiBTaW1wbGUgUG9ydCBSYW5kb21pemF0 aW9uIEFsZ29yaXRobSBJSSAqLworI2RlZmluZQlJTlBfUkZDNjA1Nl9BTEdfMwkzCS8qIFNpbXBs ZSBIYXNoLUJhc2VkIFBvcnQgU2VsZWN0aW9uIEFsZ29yaXRobSAqLworI2RlZmluZQlJTlBfUkZD NjA1Nl9BTEdfNAk0CS8qIERvdWJsZS1IYXNoIFBvcnQgU2VsZWN0aW9uIEFsZ29yaXRobSAqLwor I2RlZmluZQlJTlBfUkZDNjA1Nl9BTEdfNQk1CS8qIFJhbmRvbS1JbmNyZW1lbnRzIFBvcnQgU2Vs ZWN0aW9uIEFsZ29yaXRobSAqLworCiAjaWZkZWYgX0tFUk5FTAogVk5FVF9ERUNMQVJFKGludCwg aXBwb3J0X3Jlc2VydmVkaGlnaCk7CiBWTkVUX0RFQ0xBUkUoaW50LCBpcHBvcnRfcmVzZXJ2ZWRs b3cpOwpAQCAtNDY2LDYgKzQ3NSw4IEBACiBWTkVUX0RFQ0xBUkUoaW50LCBpcHBvcnRfcmFuZG9t dGltZSk7CiBWTkVUX0RFQ0xBUkUoaW50LCBpcHBvcnRfc3RvcHJhbmRvbSk7CiBWTkVUX0RFQ0xB UkUoaW50LCBpcHBvcnRfdGNwYWxsb2NzKTsKK1ZORVRfREVDTEFSRSh1X2ludCwgaXBwb3J0X3Jm YzYwNTZhbGcpOworVk5FVF9ERUNMQVJFKHVfaW50LCBpcHBvcnRfcmZjNjA1NmFsZzVfdHJhZGVv ZmYpOwogCiAjZGVmaW5lCVZfaXBwb3J0X3Jlc2VydmVkaGlnaAlWTkVUKGlwcG9ydF9yZXNlcnZl ZGhpZ2gpCiAjZGVmaW5lCVZfaXBwb3J0X3Jlc2VydmVkbG93CVZORVQoaXBwb3J0X3Jlc2VydmVk bG93KQpAQCAtNDgwLDYgKzQ5MSw4IEBACiAjZGVmaW5lCVZfaXBwb3J0X3JhbmRvbXRpbWUJVk5F VChpcHBvcnRfcmFuZG9tdGltZSkKICNkZWZpbmUJVl9pcHBvcnRfc3RvcHJhbmRvbQlWTkVUKGlw cG9ydF9zdG9wcmFuZG9tKQogI2RlZmluZQlWX2lwcG9ydF90Y3BhbGxvY3MJVk5FVChpcHBvcnRf dGNwYWxsb2NzKQorI2RlZmluZSBWX2lwcG9ydF9yZmM2MDU2YWxnCVZORVQoaXBwb3J0X3JmYzYw NTZhbGcpCisjZGVmaW5lIFZfaXBwb3J0X3JmYzYwNTZhbGc1X3RyYWRlb2ZmCVZORVQoaXBwb3J0 X3JmYzYwNTZhbGc1X3RyYWRlb2ZmKQogCiBleHRlcm4gc3RydWN0IGNhbGxvdXQgaXBwb3J0X3Rp Y2tfY2FsbG91dDsKIApkaWZmIC1yIDRlYTA3N2Y1NDZkZCBzcmMvc3lzL25ldGluZXQ2L2luNl9z cmMuYwotLS0gYS9zcmMvc3lzL25ldGluZXQ2L2luNl9zcmMuYwlGcmkgSmFuIDI4IDEyOjIxOjA4 IDIwMTEgKzAyMDAKKysrIGIvc3JjL3N5cy9uZXRpbmV0Ni9pbjZfc3JjLmMJRnJpIEphbiAyOCAx NjoxMDowOCAyMDExICswMjAwCkBAIC0xMDgsNiArMTA4LDggQEAKICNpbmNsdWRlIDxuZXRpbmV0 Ni9zY29wZTZfdmFyLmg+CiAjaW5jbHVkZSA8bmV0aW5ldDYvbmQ2Lmg+CiAKKyNpbmNsdWRlIDxz eXMvbWQ1Lmg+CisKIHN0YXRpYyBzdHJ1Y3QgbXR4IGFkZHJzZWxfbG9jazsKICNkZWZpbmUJQURE UlNFTF9MT0NLX0lOSVQoKQltdHhfaW5pdCgmYWRkcnNlbF9sb2NrLCAiYWRkcnNlbF9sb2NrIiwg TlVMTCwgTVRYX0RFRikKICNkZWZpbmUJQUREUlNFTF9MT0NLKCkJCW10eF9sb2NrKCZhZGRyc2Vs X2xvY2spCkBAIC05MTksMjMgKzkyMSwxOTUgQEAKIAkJbGFzdCA9IGF1eDsKIAl9CiAKLQlpZiAo ZG9yYW5kb20pCi0JCSpsYXN0cG9ydCA9IGZpcnN0ICsgKGFyYzRyYW5kb20oKSAlIChsYXN0IC0g Zmlyc3QpKTsKLQogCWNvdW50ID0gbGFzdCAtIGZpcnN0OwogCi0JZG8gewotCQlpZiAoY291bnQt LSA8IDApIHsJLyogY29tcGxldGVseSB1c2VkPyAqLwotCQkJLyogVW5kbyBhbiBhZGRyZXNzIGJp bmQgdGhhdCBtYXkgaGF2ZSBvY2N1cnJlZC4gKi8KLQkJCWlucC0+aW42cF9sYWRkciA9IGluNmFk ZHJfYW55OwotCQkJcmV0dXJuIChFQUREUk5PVEFWQUlMKTsKKwkvKgorCSAqIEFjY29yZGluZyB0 byBSRkM2MDU2IHRoZXJlIGFyZSA1IChmaXZlKSBwb3NzaWJsZSBhbGdvcml0aG1zCisJICogZm9y IHJhbmRvbSBwb3J0IGFsbG9jYXRpb24uIFVzYWdlIG9mIGEgcGFydGljdWxhciBhbGdvcml0aG0K KwkgKiBpcyBzcGVjaWZpZWQgd2l0aCB0aGUgJ25ldC5pbmV0LmlwLnBvcnRyYW5nZS5yZmM2MDU2 X2FsZ29yaXRobScKKwkgKiBzeXNjdGwgdmFyaWFibGUuIERlZmF1bHQgdmFsdWUgaXMgMSwgd2hp Y2ggcmVwcmVzZW50cyB0aGUKKwkgKiBsZWdhY3kgcmFuZG9tIHBvcnQgYWxsb2NhdGlvbiBhbGdv cml0aG0gaW4gRnJlZUJTRC4KKwkgKi8KKwlpZiAoZG9yYW5kb20pIHsKKwkJc3dpdGNoIChWX2lw cG9ydF9yZmM2MDU2YWxnKSB7CisJCWNhc2UgSU5QX1JGQzYwNTZfQUxHXzU6CS8qIFJhbmRvbS1J bmNyZW1lbnRzIFBvcnQgU2VsZWN0aW9uICovCisJCQlkbyB7CisJCQkJaWYgKGNvdW50LS0gPCAw KSB7CS8qIGNvbXBsZXRlbHkgdXNlZD8gKi8KKwkJCQkJLyogVW5kbyBhbiBhZGRyZXNzIGJpbmQg dGhhdCBtYXkgaGF2ZSBvY2N1cnJlZC4gKi8KKwkJCQkJaW5wLT5pbjZwX2xhZGRyID0gaW42YWRk cl9hbnk7CisJCQkJCXJldHVybiAoRUFERFJOT1RBVkFJTCk7CisJCQkJfQorCisJCQkJKmxhc3Rw b3J0ID0gZmlyc3QgKyAoKGFyYzRyYW5kb20oKSAlIDY1NTM2KSArCisJCQkJICAgIChhcmM0cmFu ZG9tKCkgJSBWX2lwcG9ydF9yZmM2MDU2YWxnNV90cmFkZW9mZikgKyAxKTsKKworCQkJCWlmICgq bGFzdHBvcnQgPCBmaXJzdCB8fCAqbGFzdHBvcnQgPiBsYXN0KQorCQkJCQkqbGFzdHBvcnQgPSBm aXJzdDsKKwkJCQlscG9ydCA9IGh0b25zKCpsYXN0cG9ydCk7CisJCQl9IHdoaWxlIChpbjZfcGNi bG9va3VwX2xvY2FsKHBjYmluZm8sICZpbnAtPmluNnBfbGFkZHIsCisJCQkgICAgbHBvcnQsIHdp bGQsIGNyZWQpKTsKKwkJCWJyZWFrOworCQljYXNlIElOUF9SRkM2MDU2X0FMR180OiAvKiBEb3Vi bGUtSGFzaCBQb3J0IFNlbGVjdGlvbiBBbGdvcml0aG0gKi8KKwkJCXsKKwkJCQlNRDVfQ1RYIGZf Y3R4OworCQkJCU1ENV9DVFggZ19jdHg7CisJCQkJdV9pbnQzMl90IEZbNF0gPSB7IDAsIDAsIDAs IDAgfTsKKwkJCQl1X2ludDMyX3QgR1s0XSA9IHsgMCwgMCwgMCwgMCB9OworCQkJCXVfaW50MzJf dCBzZWNyZXRfZls0XSA9IHsgMCwgMCwgMCwgMCB9OworCQkJCXVfaW50MzJfdCBzZWNyZXRfZ1s0 XSA9IHsgMCwgMCwgMCwgMCB9OworCQkJCXVfaW50MTZfdCB0YWJsZVsxNl07CisJCQkJdV9pbnQz Ml90IGluZGV4ID0gMDsKKwkJCQl1X2ludDMyX3Qgb2Zmc2V0ID0gMDsKKworCQkJCXNlY3JldF9m WzBdID0gYXJjNHJhbmRvbSgpOworCQkJCXNlY3JldF9mWzFdID0gYXJjNHJhbmRvbSgpOworCQkJ CXNlY3JldF9mWzJdID0gYXJjNHJhbmRvbSgpOworCQkJCXNlY3JldF9mWzNdID0gYXJjNHJhbmRv bSgpOworCisJCQkJc2VjcmV0X2dbMF0gPSBhcmM0cmFuZG9tKCk7CisJCQkJc2VjcmV0X2dbMV0g PSBhcmM0cmFuZG9tKCk7CisJCQkJc2VjcmV0X2dbMl0gPSBhcmM0cmFuZG9tKCk7CisJCQkJc2Vj cmV0X2dbM10gPSBhcmM0cmFuZG9tKCk7CisKKwkJCQlmb3IgKGluZGV4ID0gMDsgaW5kZXggPCBz aXplb2YodGFibGUpOyBpbmRleCsrKQorCQkJCQl0YWJsZVtpbmRleF0gPSBhcmM0cmFuZG9tKCkg JSA2NTUzNjsKKworCQkJCU1ENUluaXQoJmZfY3R4KTsKKwkJCQlNRDVVcGRhdGUoJmZfY3R4LCAo dV9jaGFyICopJmlucC0+aW42cF9sYWRkciwKKwkJCQkgICAgc2l6ZW9mKGlucC0+aW42cF9sYWRk cikpOworCQkJCU1ENVVwZGF0ZSgmZl9jdHgsICh1X2NoYXIgKikmaW5wLT5pbjZwX2ZhZGRyLAor CQkJCSAgICBzaXplb2YoaW5wLT5pbjZwX2ZhZGRyKSk7CisJCQkJTUQ1VXBkYXRlKCZmX2N0eCwg KHVfY2hhciAqKSZpbnAtPmlucF9mcG9ydCwKKwkJCQkgICAgc2l6ZW9mKGlucC0+aW5wX2Zwb3J0 KSk7CisJCQkJTUQ1VXBkYXRlKCZmX2N0eCwgKHVfY2hhciAqKXNlY3JldF9mLAorCQkJCSAgICBz aXplb2Yoc2VjcmV0X2YpKTsKKwkJCQlNRDVGaW5hbCgodV9jaGFyICopJkYsICZmX2N0eCk7CisK KwkJCQlvZmZzZXQgPSAoKEZbMF0gXiBGWzFdKSBeIChGWzJdIF4gRlszXSkpOworCisJCQkJTUQ1 SW5pdCgmZ19jdHgpOworCQkJCU1ENVVwZGF0ZSgmZ19jdHgsICh1X2NoYXIgKikmaW5wLT5pbjZw X2xhZGRyLAorCQkJCSAgICBzaXplb2YoaW5wLT5pbjZwX2xhZGRyKSk7CisJCQkJTUQ1VXBkYXRl KCZnX2N0eCwgKHVfY2hhciAqKSZpbnAtPmluNnBfZmFkZHIsCisJCQkJICAgIHNpemVvZihpbnAt PmluNnBfZmFkZHIpKTsKKwkJCQlNRDVVcGRhdGUoJmdfY3R4LCAodV9jaGFyICopJmlucC0+aW5w X2Zwb3J0LAorCQkJCSAgICBzaXplb2YoaW5wLT5pbnBfZnBvcnQpKTsKKwkJCQlNRDVVcGRhdGUo JmdfY3R4LCAodV9jaGFyICopc2VjcmV0X2csCisJCQkJICAgIHNpemVvZihzZWNyZXRfZykpOwor CQkJCU1ENUZpbmFsKCh1X2NoYXIgKikmRywgJmdfY3R4KTsKKworCQkJCWluZGV4ID0gKChHWzBd IF4gR1sxXSkgXiAoR1syXSBeIEdbM10pKSAlIHNpemVvZih0YWJsZSk7CisKKwkJCQlkbyB7CisJ CQkJCWlmIChjb3VudC0tIDwgMCkgewkvKiBjb21wbGV0ZWx5IHVzZWQ/ICovCisJCQkJCQkvKiBV bmRvIGFuIGFkZHJlc3MgYmluZCB0aGF0IG1heSBoYXZlIG9jY3VycmVkLiAqLworCQkJCQkJaW5w LT5pbjZwX2xhZGRyID0gaW42YWRkcl9hbnk7CisJCQkJCQlyZXR1cm4gKEVBRERSTk9UQVZBSUwp OworCQkJCQl9CisKKwkJCQkJKmxhc3Rwb3J0ID0gZmlyc3QgKworCQkJCQkgICAgKG9mZnNldCAr IHRhYmxlW2luZGV4XSsrKSAlIGNvdW50OworCisJCQkJCWlmICgqbGFzdHBvcnQgPCBmaXJzdCB8 fCAqbGFzdHBvcnQgPiBsYXN0KQorCQkJCQkJKmxhc3Rwb3J0ID0gZmlyc3Q7CisJCQkJCWxwb3J0 ID0gaHRvbnMoKmxhc3Rwb3J0KTsKKwkJCQl9IHdoaWxlIChpbjZfcGNibG9va3VwX2xvY2FsKHBj YmluZm8sICZpbnAtPmluNnBfbGFkZHIsCisJCQkJICAgIGxwb3J0LCB3aWxkLCBjcmVkKSk7CisJ CQl9CisJCQlicmVhazsKKwkJY2FzZSBJTlBfUkZDNjA1Nl9BTEdfMzogLyogU2ltcGxlIEhhc2gt QmFzZWQgUG9ydCBTZWxlY3Rpb24gQWxnb3JpdGhtICovCisJCQl7CisJCQkJTUQ1X0NUWCBmX2N0 eDsKKwkJCQl1X2ludDMyX3QgRls0XSA9IHsgMCwgMCwgMCwgMCB9OworCQkJCXVfaW50MzJfdCBz ZWNyZXRfZls0XSA9IHsgMCwgMCwgMCwgMCB9OworCQkJCXVfaW50MzJfdCBvZmZzZXQgPSAwOwor CisJCQkJc2VjcmV0X2ZbMF0gPSBhcmM0cmFuZG9tKCk7CisJCQkJc2VjcmV0X2ZbMV0gPSBhcmM0 cmFuZG9tKCk7CisJCQkJc2VjcmV0X2ZbMl0gPSBhcmM0cmFuZG9tKCk7CisJCQkJc2VjcmV0X2Zb M10gPSBhcmM0cmFuZG9tKCk7CisKKwkJCQlNRDVJbml0KCZmX2N0eCk7CisJCQkJTUQ1VXBkYXRl KCZmX2N0eCwgKHVfY2hhciAqKSZpbnAtPmluNnBfbGFkZHIsCisJCQkJICAgIHNpemVvZihpbnAt PmluNnBfbGFkZHIpKTsKKwkJCQlNRDVVcGRhdGUoJmZfY3R4LCAodV9jaGFyICopJmlucC0+aW42 cF9mYWRkciwKKwkJCQkgICAgc2l6ZW9mKGlucC0+aW42cF9mYWRkcikpOworCQkJCU1ENVVwZGF0 ZSgmZl9jdHgsICh1X2NoYXIgKikmaW5wLT5pbnBfZnBvcnQsCisJCQkJICAgIHNpemVvZihpbnAt PmlucF9mcG9ydCkpOworCQkJCU1ENVVwZGF0ZSgmZl9jdHgsICh1X2NoYXIgKilzZWNyZXRfZiwK KwkJCQkgICAgc2l6ZW9mKHNlY3JldF9mKSk7CisJCQkJTUQ1RmluYWwoKHVfY2hhciAqKSZGLCAm Zl9jdHgpOworCisJCQkJb2Zmc2V0ID0gKChGWzBdIF4gRlsxXSkgXiAoRlsyXSBeIEZbM10pKTsK KworCQkJCWRvIHsKKwkJCQkJaWYgKGNvdW50LS0gPCAwKSB7CS8qIGNvbXBsZXRlbHkgdXNlZD8g Ki8KKwkJCQkJCS8qIFVuZG8gYW4gYWRkcmVzcyBiaW5kIHRoYXQgbWF5IGhhdmUgb2NjdXJyZWQu ICovCisJCQkJCQlpbnAtPmluNnBfbGFkZHIgPSBpbjZhZGRyX2FueTsKKwkJCQkJCXJldHVybiAo RUFERFJOT1RBVkFJTCk7CisJCQkJCX0KKworCQkJCQkqbGFzdHBvcnQgPSBmaXJzdCArICgoYXJj NHJhbmRvbSgpICUgNjU1MzYpICsKKwkJCQkJICAgIChvZmZzZXQgJSA2NTUzNikpICUgY291bnQ7 CisKKwkJCQkJaWYgKCpsYXN0cG9ydCA8IGZpcnN0IHx8ICpsYXN0cG9ydCA+IGxhc3QpCisJCQkJ CQkqbGFzdHBvcnQgPSBmaXJzdDsKKwkJCQkJbHBvcnQgPSBodG9ucygqbGFzdHBvcnQpOworCQkJ CX0gd2hpbGUgKGluNl9wY2Jsb29rdXBfbG9jYWwocGNiaW5mbywgJmlucC0+aW42cF9sYWRkciwK KwkJCQkgICAgbHBvcnQsIHdpbGQsIGNyZWQpKTsKKwkJCX0KKwkJCWJyZWFrOworCQljYXNlIElO UF9SRkM2MDU2X0FMR18yOgkvKiBTaW1wbGUgUG9ydCBSYW5kb21pemF0aW9uIEFsZ29yaXRobSBJ SSAqLworCQkJZG8geworCQkJCWlmIChjb3VudC0tIDwgMCkgewkvKiBjb21wbGV0ZWx5IHVzZWQ/ ICovCisJCQkJCS8qIFVuZG8gYW4gYWRkcmVzcyBiaW5kIHRoYXQgbWF5IGhhdmUgb2NjdXJyZWQu ICovCisJCQkJCWlucC0+aW42cF9sYWRkciA9IGluNmFkZHJfYW55OworCQkJCQlyZXR1cm4gKEVB RERSTk9UQVZBSUwpOworCQkJCX0KKworCQkJCSpsYXN0cG9ydCA9IGZpcnN0ICsgKGFyYzRyYW5k b20oKSAlIChsYXN0IC0gZmlyc3QpKTsKKworCQkJCWlmICgqbGFzdHBvcnQgPCBmaXJzdCB8fCAq bGFzdHBvcnQgPiBsYXN0KQorCQkJCQkqbGFzdHBvcnQgPSBmaXJzdDsKKwkJCQlscG9ydCA9IGh0 b25zKCpsYXN0cG9ydCk7CisJCQl9IHdoaWxlIChpbjZfcGNibG9va3VwX2xvY2FsKHBjYmluZm8s ICZpbnAtPmluNnBfbGFkZHIsCisJCQkgICAgbHBvcnQsIHdpbGQsIGNyZWQpKTsKKwkJCWJyZWFr OworCQljYXNlIElOUF9SRkM2MDU2X0FMR18xOgkvKiBTaW1wbGUgUG9ydCBSYW5kb21pemF0aW9u IEFsZ29yaXRobSBJICovCisJCWRlZmF1bHQ6CisJCQkqbGFzdHBvcnQgPSBmaXJzdCArIChhcmM0 cmFuZG9tKCkgJSAobGFzdCAtIGZpcnN0KSk7CisKKwkJCWRvIHsKKwkJCQlpZiAoY291bnQtLSA8 IDApIHsJLyogY29tcGxldGVseSB1c2VkPyAqLworCQkJCQkvKiBVbmRvIGFuIGFkZHJlc3MgYmlu ZCB0aGF0IG1heSBoYXZlIG9jY3VycmVkLiAqLworCQkJCQlpbnAtPmluNnBfbGFkZHIgPSBpbjZh ZGRyX2FueTsKKwkJCQkJcmV0dXJuIChFQUREUk5PVEFWQUlMKTsKKwkJCQl9CisKKwkJCQkrKyps YXN0cG9ydDsKKworCQkJCWlmICgqbGFzdHBvcnQgPCBmaXJzdCB8fCAqbGFzdHBvcnQgPiBsYXN0 KQorCQkJCQkqbGFzdHBvcnQgPSBmaXJzdDsKKwkJCQlscG9ydCA9IGh0b25zKCpsYXN0cG9ydCk7 CisJCQl9IHdoaWxlIChpbjZfcGNibG9va3VwX2xvY2FsKHBjYmluZm8sICZpbnAtPmluNnBfbGFk ZHIsCisJCQkgICAgbHBvcnQsIHdpbGQsIGNyZWQpKTsKIAkJfQotCQkrKypsYXN0cG9ydDsKLQkJ aWYgKCpsYXN0cG9ydCA8IGZpcnN0IHx8ICpsYXN0cG9ydCA+IGxhc3QpCi0JCQkqbGFzdHBvcnQg PSBmaXJzdDsKLQkJbHBvcnQgPSBodG9ucygqbGFzdHBvcnQpOwotCX0gd2hpbGUgKGluNl9wY2Js b29rdXBfbG9jYWwocGNiaW5mbywgJmlucC0+aW42cF9sYWRkciwKLQkgICAgbHBvcnQsIHdpbGQs IGNyZWQpKTsKKwl9IGVsc2UgeworCQlkbyB7CisJCQlpZiAoY291bnQtLSA8IDApIHsJLyogY29t cGxldGVseSB1c2VkPyAqLworCQkJCS8qIFVuZG8gYW4gYWRkcmVzcyBiaW5kIHRoYXQgbWF5IGhh dmUgb2NjdXJyZWQuICovCisJCQkJaW5wLT5pbjZwX2xhZGRyID0gaW42YWRkcl9hbnk7CisJCQkJ cmV0dXJuIChFQUREUk5PVEFWQUlMKTsKKwkJCX0KKworCQkJKysqbGFzdHBvcnQ7CisKKwkJCWlm ICgqbGFzdHBvcnQgPCBmaXJzdCB8fCAqbGFzdHBvcnQgPiBsYXN0KQorCQkJCSpsYXN0cG9ydCA9 IGZpcnN0OworCQkJbHBvcnQgPSBodG9ucygqbGFzdHBvcnQpOworCQl9IHdoaWxlIChpbjZfcGNi bG9va3VwX2xvY2FsKHBjYmluZm8sICZpbnAtPmluNnBfbGFkZHIsCisJCSAgICBscG9ydCwgd2ls ZCwgY3JlZCkpOworCX0KIAogCWlucC0+aW5wX2xwb3J0ID0gbHBvcnQ7CiAJaWYgKGluX3BjYmlu c2hhc2goaW5wKSAhPSAwKSB7Cg== --0015175cb99ae421ce049ae8f559-- From owner-freebsd-net@FreeBSD.ORG Fri Jan 28 16:10:42 2011 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 9B9491065728; Fri, 28 Jan 2011 16:10:42 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id 508378FC12; Fri, 28 Jan 2011 16:10:42 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a] (saphire3.sentex.ca [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a]) by smarthost1.sentex.ca (8.14.4/8.14.4) with ESMTP id p0SGAdR5009374 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 28 Jan 2011 11:10:40 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <4D42EA74.4090807@sentex.net> Date: Fri, 28 Jan 2011 11:10:28 -0500 From: Mike Tancsa User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Jan Koum References: <1290533941.3173.50.camel@home-yahoo> <4CEC0548.1080801@sentex.net> <4D2C636B.5040003@sentex.net> <4D3C4795.40205@sentex.net> In-Reply-To: <4D3C4795.40205@sentex.net> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on IPv6:2607:f3e0:0:1::12 Cc: "freebsd-net@freebsd.org" , Jack Vogel , Ivan Voras , Sean Bruno , "freebsd-hardware@freebsd.org" Subject: Re: em driver, 82574L chip, and possibly ASPM 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, 28 Jan 2011 16:10:42 -0000 On 1/23/2011 10:21 AM, Mike Tancsa wrote: > On 1/21/2011 4:21 AM, Jan Koum wrote: > One other thing I noticed is that when the nic is in its hung state, the > WOL option is gone ? > > e.g > > em1: flags=8843 metric 0 mtu 1500 > options=19b > ether 00:15:17:ed:68:a4 > > vs > > > em1: flags=8843 metric 0 mtu 1500 > > options=219b > ether 00:15:17:ed:68:a4 Another hang last night :( Whats really strange is that the WOL_MAGIC and TSO4 got turned back on somehow ? I had explicitly turned it off, but when the NIC was in its bad state em1: flags=8843 metric 0 mtu 1500 options=2198 ... its back on along with TSO? Not sure if its coincidence or a side effect or what. For now, I have had to re-purpose this nic to something else. debug info shows Jan 28 00:25:10 backup3 kernel: Interface is RUNNING and INACTIVE Jan 28 00:25:10 backup3 kernel: em1: hw tdh = 625, hw tdt = 625 Jan 28 00:25:10 backup3 kernel: em1: hw rdh = 903, hw rdt = 903 Jan 28 00:25:10 backup3 kernel: em1: Tx Queue Status = 0 Jan 28 00:25:10 backup3 kernel: em1: TX descriptors avail = 1024 Jan 28 00:25:10 backup3 kernel: em1: Tx Descriptors avail failure = 0 Jan 28 00:25:10 backup3 kernel: em1: RX discarded packets = 0 Jan 28 00:25:10 backup3 kernel: em1: RX Next to Check = 903 Jan 28 00:25:10 backup3 kernel: em1: RX Next to Refresh = 904 Jan 28 00:25:27 backup3 kernel: em1: link state changed to DOWN Jan 28 00:25:30 backup3 kernel: em1: link state changed to UP ---Mike From owner-freebsd-net@FreeBSD.ORG Fri Jan 28 18:09:56 2011 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 83A89106564A for ; Fri, 28 Jan 2011 18:09:56 +0000 (UTC) (envelope-from ddesimone@verio.net) Received: from relay1-bcrtfl2.verio.net (relay1-bcrtfl2.verio.net [131.103.218.142]) by mx1.freebsd.org (Postfix) with ESMTP id 36B1D8FC23 for ; Fri, 28 Jan 2011 18:09:56 +0000 (UTC) Received: from iad-wprd-xchw02.corp.verio.net (unknown [198.87.7.165]) by relay1-bcrtfl2.verio.net (Postfix) with ESMTP id D9531B038CFB for ; Fri, 28 Jan 2011 12:39:24 -0500 (EST) Thread-Index: Acu/Ek3IrOZJm+htRjaqt4XdBTnddw== Received: from dllstx1-8sst9f1.corp.verio.net ([10.144.2.50]) by iad-wprd-xchw02.corp.verio.net over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 28 Jan 2011 12:39:23 -0500 Received: by dllstx1-8sst9f1.corp.verio.net (sSMTP sendmail emulation); Fri, 28 Jan 2011 11:39:22 -0600 Content-Transfer-Encoding: 7bit Date: Fri, 28 Jan 2011 11:39:21 -0600 From: "David DeSimone" To: Content-class: urn:content-classes:message Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4721 Message-ID: <20110128173921.GY316@verio.net> Mail-Followup-To: freebsd-net@freebsd.org References: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: Precedence: bulk User-Agent: Mutt/1.5.20 (2009-12-10) X-OriginalArrivalTime: 28 Jan 2011 17:39:23.0488 (UTC) FILETIME=[4D268E00:01CBBF12] Subject: Re: CARP Failover X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 18:09:56 -0000 Mike Barnard wrote: > > FW1 is connected to SW1 and FW2 is connected to SW2. Both SW1 and SW2 > connected to the aggregating switch. > > I have configured CARP in failover mode and the interesting thing is both > firewall carp interfaces come up as master: > > FW1: > carp0: flags=49 metric 0 mtu 1500 > inet 41.xxx.yyy.243 netmask 0xfffffff8 > carp: MASTER vhid 1 advbase 1 advskew 1 > carp1: flags=49 metric 0 mtu 1500 > inet 41.xxx.yyy.251 netmask 0xfffffff8 > carp: MASTER vhid 2 advbase 1 advskew 1 > > FW2: > carp0: flags=49 metric 0 mtu 1500 > inet 41.xxx.yyy.243 netmask 0xfffffff8 > carp: MASTER vhid 1 advbase 1 advskew 100 > carp1: flags=49 metric 0 mtu 1500 > inet 41.xxx.yyy.251 netmask 0xfffffff8 > carp: MASTER vhid 2 advbase 1 advskew 100 The two firewalls cannot hear each other's CARP announcements. Test with tcpdump; do you see the CARP packets coming from the other firewall? If not, you have a switching problem, like the two firewalls are not in the same VLAN together. If you do see the packets arriving, it probably means that your PF policy is blocking CARP from your neighbor. -- David DeSimone == Network Admin == fox@verio.net "I don't like spinach, and I'm glad I don't, because if I liked it I'd eat it, and I just hate it." -- Clarence Darrow This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free. Thank you. From owner-freebsd-net@FreeBSD.ORG Fri Jan 28 19:00:49 2011 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 5D94010656B8 for ; Fri, 28 Jan 2011 19:00:49 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with ESMTP id 5AE788FC1D for ; Fri, 28 Jan 2011 19:00:46 +0000 (UTC) Received: (qmail 23098 invoked by uid 399); 28 Jan 2011 19:00:42 -0000 Received: from localhost (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 28 Jan 2011 19:00:42 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4D431258.8040704@FreeBSD.org> Date: Fri, 28 Jan 2011 11:00:40 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.13) Gecko/20101212 Thunderbird/3.1.7 MIME-Version: 1.0 To: Ivo Vachkov References: <4D411CC6.1090202@gont.com.ar> In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net , bz@freebsd.org Subject: Re: Proposed patch for Port Randomization modifications according to RFC6056 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, 28 Jan 2011 19:00:49 -0000 On 01/28/2011 06:33, Ivo Vachkov wrote: > Hello, > > I would like to thank for the help and for the recommendations. > > I attach second version of the patch, I proposed earlier, including > following changes: > > 1) All RFC6056 algorithms are implemented. > 2) Both IPv4 and IPv6 stacks are modified to use the new port > randomization code. > 3) There are two variables that can be modified via sysctl: > - net.inet.ip.portrange.rfc6056_algorithm - which allows the super > user to choose one out of the five possible algorithms. > - net.inet.ip.portrange.rfc6056_algorithm5_tradeoff - which allows the > super user to modify the trade-off value used in algorithm 5. > All values are explicitly checked for correctness before usage. > Default values for those variables represent current/legacy port > randomization algorithm and proposed values in the RFC itself. I haven't reviewed the patch in detail yet but I wanted to first thank you for taking on this work, and being so responsive to Fernando's request (which I agreed with, and you updated before I even had a chance to say so). :) My one comment so far is on the name of the sysctl's. There are 2 problems with sysctl/variable names that use an rfc title. The first is that they are not very descriptive to the 99.9% of users who are not familiar with that particular doc. The second is more esoteric, but if the rfc is subsequently updated or obsoleted we're stuck with either an anachronism or updating code (both of which have their potential areas of confusion). So in order to avoid this issue, and make it more consistent with the existing: net.inet.ip.portrange.randomtime net.inet.ip.portrange.randomcps net.inet.ip.portrange.randomized How does net.inet.ip.portrange.randomalg sound? I would also suggest that the second sysctl be named net.inet.ip.portrange.randomalg.alg5_tradeoff so that one could do 'sysctl net.inet.ip.portrange.randomalg' and see both values. But I won't quibble on that. :) hth, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-net@FreeBSD.ORG Fri Jan 28 19:57:22 2011 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 2D9AC106564A; Fri, 28 Jan 2011 19:57:22 +0000 (UTC) (envelope-from ivo.vachkov@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id A4D338FC13; Fri, 28 Jan 2011 19:57:21 +0000 (UTC) Received: by qyk36 with SMTP id 36so3598908qyk.13 for ; Fri, 28 Jan 2011 11:57:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=la0D3C2XoQ0b68JzYanta6T4KyuQziPKukZu8X5Hsqc=; b=oVxzLzB7avB8jrUNQm6JEtJJkQ0vOJmAgH9jFQACsNczKjodGDWOLcxX7BiHS0epXv TpAerv4tZUYx0PHIJw17kogXk3kYXe8uUfgU+qc25/5ZVSQrzTkiUNJrihgXMxbrFfiO zGjMkm4TbF5mX394X0li/sKAwyJ/S0/wfEOG0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=GHI7BNHUYWJg3R6RAJADyglA//AwqfLlSJHuzdaEQ9Q+5rtaZWlh/cFYoWw9sWjkBI NHoP2QOnW7SmUld2MbCxjV/YerzGgAqthhn9vCKxyfZZ/b1pMbLSI6RB/cBG6dqtdfxs 9lKfjgmPWh2770ldnkyQ/eZeHbku0BvY+Xows= Received: by 10.224.89.85 with SMTP id d21mr3328465qam.162.1296244640695; Fri, 28 Jan 2011 11:57:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.193.9 with HTTP; Fri, 28 Jan 2011 11:57:00 -0800 (PST) In-Reply-To: <4D431258.8040704@FreeBSD.org> References: <4D411CC6.1090202@gont.com.ar> <4D431258.8040704@FreeBSD.org> From: Ivo Vachkov Date: Fri, 28 Jan 2011 21:57:00 +0200 Message-ID: To: Doug Barton Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Net , bz@freebsd.org Subject: Re: Proposed patch for Port Randomization modifications according to RFC6056 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, 28 Jan 2011 19:57:22 -0000 On Fri, Jan 28, 2011 at 9:00 PM, Doug Barton wrote: > On 01/28/2011 06:33, Ivo Vachkov wrote: >> >> Hello, >> >> I would like to thank for the help and for the recommendations. >> >> I attach second version of the patch, I proposed earlier, including >> following changes: >> >> 1) All RFC6056 algorithms are implemented. >> 2) Both IPv4 and IPv6 stacks are modified to use the new port >> randomization code. >> 3) There are two variables that can be modified via sysctl: >> - net.inet.ip.portrange.rfc6056_algorithm - which allows the super >> user to choose one out of the five possible algorithms. >> - net.inet.ip.portrange.rfc6056_algorithm5_tradeoff - which allows the >> super user to modify the trade-off value used in algorithm 5. >> All values are explicitly checked for correctness before usage. >> Default values for those variables represent current/legacy port >> randomization algorithm and proposed values in the RFC itself. > > I haven't reviewed the patch in detail yet but I wanted to first thank you > for taking on this work, and being so responsive to Fernando's request > (which I agreed with, and you updated before I even had a chance to say so). > :) > > My one comment so far is on the name of the sysctl's. There are 2 problems > with sysctl/variable names that use an rfc title. The first is that they are > not very descriptive to the 99.9% of users who are not familiar with that > particular doc. The second is more esoteric, but if the rfc is subsequently > updated or obsoleted we're stuck with either an anachronism or updating code > (both of which have their potential areas of confusion). > > So in order to avoid this issue, and make it more consistent with the > existing: > > net.inet.ip.portrange.randomtime > net.inet.ip.portrange.randomcps > net.inet.ip.portrange.randomized > > How does net.inet.ip.portrange.randomalg sound? I would also suggest that > the second sysctl be named net.inet.ip.portrange.randomalg.alg5_tradeoff so > that one could do 'sysctl net.inet.ip.portrange.randomalg' and see both > values. But I won't quibble on that. :) > I have no objections with this. Since this is my first attempt to contribute something back to the community I decided to see how it's done before. So I found: net.inet.tcp.rfc1323 net.inet.tcp.rfc3465 net.inet.tcp.rfc3390 net.inet.tcp.rfc3042 which probably led me in a wrong direction :) I understand your point and agree with it. However, my somewhat limited understanding of the sysctl internal organization is telling me that tree node does not support values. Am I wrong? If my reasoning is correct, maybe I can create the sysctl variables with the following names: - net.inet.ip.portrange.randomalg (Tree Node) - net.inet.ip.portrange.randomalg.alg[orithm] (Leaf Node, to store the selected algorithm) - net.inet.ip.portrange.randomalg.alg5_tradeoff (Leaf Node, to store the Algorithm 5 trade-off value) Ivo Vachkov From owner-freebsd-net@FreeBSD.ORG Fri Jan 28 23:59:06 2011 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 8A3351065672; Fri, 28 Jan 2011 23:59:06 +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 60B248FC18; Fri, 28 Jan 2011 23:59:06 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p0SNx6BU079186; Fri, 28 Jan 2011 23:59:06 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p0SNx6OV079182; Fri, 28 Jan 2011 23:59:06 GMT (envelope-from linimon) Date: Fri, 28 Jan 2011 23:59:06 GMT Message-Id: <201101282359.p0SNx6OV079182@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/154169: [multicast] [ip6] Node Information Query multicast address wrong (FF02::2:x:y) 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, 28 Jan 2011 23:59:06 -0000 Old Synopsis: Node Information Query multicast address wrong (FF02::2:x:y) New Synopsis: [multicast] [ip6] Node Information Query multicast address wrong (FF02::2:x:y) Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Jan 28 23:58:32 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=154169 From owner-freebsd-net@FreeBSD.ORG Sat Jan 29 00:01:14 2011 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 4699D106566B; Sat, 29 Jan 2011 00:01:14 +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 16B568FC18; Sat, 29 Jan 2011 00:01:14 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p0T01Dgd085249; Sat, 29 Jan 2011 00:01:13 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p0T01DfV085240; Sat, 29 Jan 2011 00:01:13 GMT (envelope-from linimon) Date: Sat, 29 Jan 2011 00:01:13 GMT Message-Id: <201101290001.p0T01DfV085240@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: conf/154062: [vlan] [patch] change to way of auto-generatation of vlan devices based on the chosen parent device 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, 29 Jan 2011 00:01:14 -0000 Old Synopsis: [ patch ] change to way of auto-generatation of vlan devices based on the chosen parent device New Synopsis: [vlan] [patch] change to way of auto-generatation of vlan devices based on the chosen parent device Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat Jan 29 00:00:29 UTC 2011 Responsible-Changed-Why: Although part of the patch affects rc.d, the overall patch should probably be reviewed by -net. http://www.freebsd.org/cgi/query-pr.cgi?pr=154062 From owner-freebsd-net@FreeBSD.ORG Sat Jan 29 02:27:35 2011 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 9DAD91065672 for ; Sat, 29 Jan 2011 02:27:35 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with ESMTP id 0AA238FC15 for ; Sat, 29 Jan 2011 02:27:34 +0000 (UTC) Received: (qmail 3132 invoked by uid 399); 29 Jan 2011 02:27:33 -0000 Received: from localhost (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 29 Jan 2011 02:27:33 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4D437B13.1070405@FreeBSD.org> Date: Fri, 28 Jan 2011 18:27:31 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.13) Gecko/20101212 Thunderbird/3.1.7 MIME-Version: 1.0 To: Ivo Vachkov References: <4D411CC6.1090202@gont.com.ar> <4D431258.8040704@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net , bz@freebsd.org Subject: Re: Proposed patch for Port Randomization modifications according to RFC6056 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, 29 Jan 2011 02:27:35 -0000 On 01/28/2011 11:57, Ivo Vachkov wrote: > On Fri, Jan 28, 2011 at 9:00 PM, Doug Barton wrote: >> How does net.inet.ip.portrange.randomalg sound? I would also suggest that >> the second sysctl be named net.inet.ip.portrange.randomalg.alg5_tradeoff so >> that one could do 'sysctl net.inet.ip.portrange.randomalg' and see both >> values. But I won't quibble on that. :) >> > > I have no objections with this. Since this is my first attempt to > contribute something back to the community I decided to see how it's > done before. So I found: > net.inet.tcp.rfc1323 > net.inet.tcp.rfc3465 > net.inet.tcp.rfc3390 > net.inet.tcp.rfc3042 > which probably led me in a wrong direction :) Yeah, I had actually intended to say something to the effect of "there are plenty of unfortunate examples in the tree already so your doing it that way is totally understandable" but I trimmed it. > I understand your point and agree with it. However, my somewhat > limited understanding of the sysctl internal organization is telling > me that tree node does not support values. Am I wrong? You are likely correct. :) It's an inconvenient fact that often forget because that's not the sandbox that I usually play in. > If my reasoning > is correct, maybe I can create the sysctl variables with the following > names: > - net.inet.ip.portrange.randomalg (Tree Node) > - net.inet.ip.portrange.randomalg.alg[orithm] (Leaf Node, to store the > selected algorithm) I would go with "version" to increase the visual distinctiveness. I searched the current tree and there doesn't seem to be a clear winner for how to portray "this is the current N/M that is in use" but "version" seems to have the most representatives. > - net.inet.ip.portrange.randomalg.alg5_tradeoff (Leaf Node, to store > the Algorithm 5 trade-off value) I'm assuming this is the "N" value mentioned in the RFC. If so, I commend you on your choice of "tradeoff" to represent it. :) hth, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/