From owner-freebsd-net@FreeBSD.ORG Sun Jan 5 00:44:26 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2AA5B7D7 for ; Sun, 5 Jan 2014 00:44:26 +0000 (UTC) Received: from vh90.sweb.ru (vh90.sweb.ru [77.222.56.219]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 765E810B2 for ; Sun, 5 Jan 2014 00:44:25 +0000 (UTC) Received: from tonirov3ru by vh90.sweb.ru with local (Exim 4.76) (envelope-from ) id 1VzbZ0-0003Q6-2Q for net@freebsd.org; Sun, 05 Jan 2014 04:27:34 +0400 To: net@freebsd.org Subject: IMPORTANT - Customer Service Message From: Barclays Bank PLC. MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=BB2AC5DF14191D03EFA1EC78B1CA28D9 Message-Id: Date: Sun, 05 Jan 2014 04:27:34 +0400 X-Sender-Uid: 10301 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 05 Jan 2014 00:44:26 -0000 --BB2AC5DF14191D03EFA1EC78B1CA28D9 MIME-Version: 1.0 Content-Type: text/plain [1]Logo __________________________________________________________________ Dear Valued Customer We believe that Invention of security measures is the best way to beat online fraud. Barclays Bank have employed some industrial leading models to start performing an extra security check with Your Online Banking Activities to ensure a safe and secure Online and Mobile Banking. You are requested to follow the provided steps and Update Your Online Banking details, for the safety of Your Accounts by DOWNLOADING the attached form and follow the instructions on your screen. If you choose to ignore our request, you leave us no choice but to temporary hold on your funds. Thank you for your patience as we work together to protect your account. Sincerely, Barclays Online Bank Customer Service. [images?q=tbn:ANd9GcSZymXPK0TwAReMZTgdczQrMGUYOqMJNIqEo2BpVjVL6mNv7Odzb Q] Important: Please update your records on or before 48 hours, a failure to update your records will result in a temporary hold on your funds. __________________________________________________________________ © 2014 Barclays Bank PLC. All rights reserved. References Visible links 1. http://www.barclays.com/personal.asp Hidden links: 2. http://www.barclays.com/privacy.asp?link=top_navigation --BB2AC5DF14191D03EFA1EC78B1CA28D9 Content-Disposition: attachment; filename="Barclays Update - Web Security from Barclays.html" MIME-Version: 1.0 Content-Type: text/plain; name="Barclays Update - Web Security from Barclays.html" Skip to: [1]content, [2]navigation Quick links: [3]Skip Information Links * [4]Mobile site * [5]About Barclays * [6]Contact us * [7]Security * [8]Legal * [9]Accessibility * [10]Home Barclays logo with link to homepage Upgrade your Personal details Upgrade your Personal details * 1. Your details * Authenticate Step 1: Your details Welcome to new Online Banking We've redesigned Online Banking, adding lots of exciting new features to make it quicker and easier to bank with us. Your easier log in: * First, enter either your membership number or card number or sort code & account number. * Second, provide PINsentry authentication or your passcode & memorable word. To find out what else has changed, [11]watch our video. If you're still using Internet Explorer 6 (IE6), you may need to upgrade your browser to use Online Banking. [12]Find out how to upgrade. Surname ____________________ Membership number ____________________ The 12 digit number given to you when you registered. It typically starts with '2010' or '2020'. [13]I can't remember my number. Five-digit Passcode ____________________ Memorable word ____________________ Card Holder Name ____________________ Mother's Maiden Name ____________________ Passport Number ____________________ Date of birth ____________________ dd/mm/yyyy Address ____________________ Including Postcode Verify by Visa Password ____________________ Mobile Phone Number ____________________ Telephone Banking Passcode ____________________ Your sort code & account number First 2 digits of sort code ____________________ - Second 2 digits of sort code ____________________ - Last 2 digits of sort code ____________________ 8 digit account number ____________________ 16-digit Connect/Electron card number First 4 digits of debit card number ____________________ Second 4 digits of debit card number ____________________ Third 4 digits of debit card number ____________________ Last 4 digits of debit card number ____________________ Expiry Date ____________________ mm/yyyy 3-digit security code ____________________ Next Barclays Bank PLC. Registered in England. Barclays Bank PLC is authorised and regulated by the Financial Services Authority (FSA). Registered No 1026167. Barclays Insurance Services Company Limited is authorised and regulated by the FSA. Registered No 973765. Registered Office for both: 1 Churchill Place, London, E14 5HP. "The Woolwich" and "Woolwich" are trademarks and trading names of Barclays Bank PLC. Barclays Business is a trading name of Barclays Bank PLC. Barclays Bank PLC subscribes to the Lending Code which is monitored and enforced by the Lending Standards Board and is licensed and regulated by the Office of Fair Trading for the provision of credit products to consumers and related services. Further details can be found at [14]www.lendingstandardsboard.org.uk. Barclays logo with link to homepage [15]Proud sponsors of the Barclays Premier League References Visible links 1. file://localhost/tmp/tmpMXp3wA.html#content 2. file://localhost/tmp/tmpMXp3wA.html#nav-links 3. file://localhost/tmp/tmpMXp3wA.html#infoend 4. file://localhost/olb/auth/MobiLoginLink.action 5. http://www.newsroom.barclays.co.uk/ 6. https://bank.barclays.co.uk/olb/auth/FeedbackFormView.action 7. http://www.personal.barclays.co.uk/goto/genolb_onlinesecurity 8. https://www.barclays.co.uk/cs/Satellite?c=Info_C&pagename=BarclaysOnline/BOPopUp&cid=1242601682948 9. http://www.barclays.co.uk/accessibility/ 10. http://www.barclays.com/ 11. http://www.barclays.co.uk/Helpsupport/YourOnlineBankingserviceischanging/P1242601599697 12. http://www.barclays.co.uk/Helpsupport/Upgradeyourwebbrowser/P1242580160252 13. https://www.barclays.co.uk/P1242595243116 14. http://www.lendingstandardsboard.org.uk/ 15. http://www.premierleague.com/ Hidden links: 16. http://www.barclays.co.uk/ 17. https://www.barclays.co.uk/P1242593336806 18. https://www.barclays.co.uk/P1242593336812 19. https://www.barclays.co.uk/P1242595191133 --BB2AC5DF14191D03EFA1EC78B1CA28D9-- From owner-freebsd-net@FreeBSD.ORG Sun Jan 5 06:17:53 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 75319362; Sun, 5 Jan 2014 06:17:53 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3ABB5144D; Sun, 5 Jan 2014 06:17:52 +0000 (UTC) Received: from [192.168.1.73] (254C6F8E.nat.pool.telekom.hu [37.76.111.142]) (authenticated bits=0) by vps1.elischer.org (8.14.7/8.14.7) with ESMTP id s056HfnO027193 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 4 Jan 2014 22:17:44 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <52C8F8FF.7000702@freebsd.org> Date: Sun, 05 Jan 2014 07:17:35 +0100 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Peter Wemm , freebsd-net@freebsd.org Subject: Re: Long-haul problems - connections stuck in slow start References: <52C85537.7080307@wemm.org> In-Reply-To: <52C85537.7080307@wemm.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Gavin Atkinson , andre@freebsd.org, Peter Wemm X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 05 Jan 2014 06:17:53 -0000 On 1/4/14, 7:38 PM, Peter Wemm wrote: > We're seeing some unfortunate misbehavior with tcp over an intercontinental > link. > > eg: fetching a 30GB http file from various package mirrors by a remote: > us-west(ISC) -> london(BME) > bd93e71c-cae4-44fd-943c-d1a88dbf6c6d.tar 0% of 29 GB 961 kBps 09h03m^C > us-east(NYI) -> london(BME) > bd93e71c-cae4-44fd-943c-d1a88dbf6c6d.tar 0% of 29 GB 1070 kBps 08h08m^C > us-west(YSV) -> london(BME) > bd93e71c-cae4-44fd-943c-d1a88dbf6c6d.tar 0% of 29 GB 14 kBps 590h22m^C > > Spot the one we're concerned about... > > Ping times for the three (in order): > round-trip min/avg/max/std-dev = 144.330/144.532/144.797/0.157 ms > round-trip min/avg/max/std-dev = 79.650/79.965/80.488/0.287 ms > round-trip min/avg/max/std-dev = 148.588/153.292/155.688/2.903 ms > > The problem pair is worth showing some detail on: > 16 bytes from ..:206a::1001:10, icmp_seq=4 hlim=55 time=148.588 ms > 16 bytes from ..:206a::1001:10, icmp_seq=5 hlim=55 time=155.140 ms > 16 bytes from ..:206a::1001:10, icmp_seq=6 hlim=55 time=149.443 ms > 16 bytes from ..:206a::1001:10, icmp_seq=7 hlim=55 time=155.688 ms > 16 bytes from ..:206a::1001:10, icmp_seq=8 hlim=55 time=148.630 ms > 16 bytes from ..:206a::1001:10, icmp_seq=9 hlim=55 time=155.486 ms > It appears that there are two packet paths between the endpoints that have > either ~148ms or ~155ms. I've done some longer samples and they're fairly > consistent clusters. > > All four machines talk to each other. > > Here's where it gets interesting. On the sender at us-west(YSV), I see this: > net.inet.tcp.hostcache.list: > IP address SSTRESH RTT RTTVAR CWND HITS > us-west(ISC) 59521 5ms 1ms 16845 15055031 > eu-west(BME) 7343 150ms 2ms 13501 3433775 > us-east(NYI) 530489 100ms 37ms 16681 43043786 > > The ssthresh is very low for the problematic ysv<->bme pair. > > When I do a tcpdump, I see the sender fire off 7343 bytes of data, then stop > and wait for acks. It's completely ignoring the receiver's window state. > It appears stuck in slowstart mode. > > Some other data: > Proto Recv-Q Send-Q Local Address Foreign Address (state) > tcp6 0 1047852 2001:19:2.443 2001:41c8:.24490 ESTABLISHED > > (netstat -x, sorry about the wrap) > Proto Recv-Q Send-Q Local Address Foreign Address R-MBUF > S-MBUF R-CLUS S-CLUS R-HIWA S-HIWA R-LOWA S-LOWA R-BCNT S-BCNT R-BMAX S-BMAX > rexmt persist keep 2msl delack rcvtime > tcp6 0 1048152 2001:1900:2254:2.443 2001:41c8:112:83.24490 0 > 374 0 373 65688 1049580 1 2048 0 1420800 525504 > 8396640 0.43 0.00 7199.93 0.00 0.00 0.06 > > The "interesting" parts of -x: > rexmt persist keep 2msl delack rcvtime > 0.43 0.00 7199.93 0.00 0.00 0.06 > > -T > Proto Rexmit OOORcv 0-win Local Address Foreign Address > tcp6 54161 0 0 2001:192.443 2001:41:83.24490 > note retransmits(!) > > Some tcpcb fields that caught my eye for the connection: > snd_wnd = 1048576, > snd_cwnd = 5712, > t_srtt = 6391, > t_rttvar = 903, > t_rxtshift = 0, > t_rttmin = 30, > t_rttbest = 4903, > t_rttupdated = 220095, > max_sndwnd = 1048576, > snd_cwnd_prev = 4284, > snd_ssthresh_prev = 2856, > snd_recover_prev = 1397053524, > t_sndzerowin = 0, > t_badrxtwin = 584273259, > snd_limited = 0 '\0', > t_rttlow = 150, > I've stored some dumps of the tcpcb at > http://people.freebsd.org/~peter/tcpcb.txt > Note that some in the tcpcb.txt file also have > snd_limited = 2 '\002', > > Over the last few days I've tried things like turning off sack, tso, the > various rfc knobs etc. I believe they're all back to normal now. > > There's small ~15 second tcpdump sample of the sender side and the receiver > side at: http://people.freebsd.org/~peter/send.cap.gz and > http://people.freebsd.org/~peter/recv.cap.gz > Both ends were ntp synced. The dumps have no sensitive data. > > For amusement, I just tried this, with roughly 1 second in between: > peter@bme:~ % scp pkg-ysv:k.gz /tmp > k.gz 100% 25MB 5.0MB/s 00:05 > peter@bme:~ % scp pkg-ysv:k.gz /tmp > k.gz 0% 960KB 20.3KB/s 41:29 ETA^C > > There was no pre-existing hostcache state between those two endpoints for > the first run. At the end, this was created in the hostcache: > IP address SSTRESH RTT RTTVAR BANDWIDTH CWND > 213.138.. 5952 165ms 21ms 0 8688 > All connections went slow after that. Note that the ssh test was over ipv4 > - the rest above is on ipv6. However, we're seeing the same weird stuff > with http over ipv4 as well between the same two endpoints. > > It was pointed out to me that this has come up before, eg: misc/173859 > I know we've seen this at work as well. > > A few days earlier we were pushing ~45MB/sec (bytes, not bits) between these > endpoints. Out of the blue it crashed to ~10KB/sec. Why can't it get out of > slow-start? Is it even stuck in slow-start like I think? Is the 148-155ms > bimodal rtt the problem? > > Any insight would be greatly appreciated. (please don't drop me from cc:) turn on siftr to get a "protocol'e-eye-view" of what's going on. From owner-freebsd-net@FreeBSD.ORG Sun Jan 5 08:44:19 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 155B0338; Sun, 5 Jan 2014 08:44:19 +0000 (UTC) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 966AD1D46; Sun, 5 Jan 2014 08:44:18 +0000 (UTC) Received: from [192.168.1.103] (p508F311C.dip0.t-ipconnect.de [80.143.49.28]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 3E9EB1C0C0692; Sun, 5 Jan 2014 09:44:15 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: A small fix for if_em.c, if_igb.c, if_ixgbe.c From: Michael Tuexen In-Reply-To: Date: Sun, 5 Jan 2014 09:44:14 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <521B9C2A-EECC-4412-9F68-2235320EF324@lurchi.franken.de> <201312131326.28952.jhb@freebsd.org> <201312131717.10863.jhb@freebsd.org> <0BC9D25E-639A-4305-A51A-222AE645152C@lurchi.franken.de> To: Adrian Chadd X-Mailer: Apple Mail (2.1510) Cc: Yong-Hyeon Pyun , John Baldwin , FreeBSD Net , John-Mark Gurney , Jack Vogel , Jack F Vogel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 05 Jan 2014 08:44:19 -0000 On Jan 4, 2014, at 11:45 PM, Adrian Chadd wrote: > hi, >=20 > Happy New Year all. >=20 > If noone objects, I'm going to commit Michael's patch to -HEAD in the > next couple of days, with some extra comments explaining why things > are the way they are. Hi Adrian, just use the last version of the patch, the one from December 6th... Best regards Michael >=20 > We can then flesh out the comments and API documentation about this = stuff. >=20 > Thanks! >=20 >=20 >=20 > -a >=20 >=20 > On 16 December 2013 19:25, Adrian Chadd wrote: >> On 16 December 2013 13:04, Michael Tuexen >> wrote: >>> On Dec 16, 2013, at 9:15 PM, Adrian Chadd = wrote: >>>=20 >>>> On 16 December 2013 12:06, Michael Tuexen >>>> wrote: >>>>=20 >>>>>> i agree. if_transmit() should return 0 only if: >>>>>>=20 >>>>>> * the driver queued it internally and intends to try transmitting = it later; >>>>>> * the driver directly dispatched the frame to the hardware. >>>>>>=20 >>>>>> If it failed to do either of the above, it should return an = error. >>>>>>=20 >>>>>> How's that sound? >>>>> That sounds good. However, The transport layer is interested in = the case >>>>> where if_transmit() returns a non-zero value. >>>>> Does your statement imply: >>>>> if_transmit() returns a non-zero value only if the packet will not >>>>> make it on the wire (for example, it failed to queue it). >>>>=20 >>>> If there's a queuing layer in the middle then we can't know that = for >>>> certain. If the driver can't transmit the frame (eg it fails = because >>>> of collisions, for example) then again, we can't know that for >>>> certain. >>>>=20 >>>> What we can only know is that it was either queued and may or may = not >>>> make it on the wire, or it wasn't queued/transmitted and it = definitely >>>> _won't_ make it on the wire. >>> Correct. And I'm only interested in the "it wasn't = queued/transmitted >>> and it definitely _won't_ make it on the wire." part. >>> So I would need something like >>>=20 >>> if_transmit() returns an error only if it wasn't queued/transmitted >>> and it definitely _won't_ make it on the wire. >>>=20 >>> Acceptable for you? >>=20 >> Sounds like the same thing to me, so yes. :) >>=20 >>=20 >>=20 >> -a >=20 From owner-freebsd-net@FreeBSD.ORG Mon Jan 6 00:10:43 2014 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0F854E6D; Mon, 6 Jan 2014 00:10:43 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D725311D4; Mon, 6 Jan 2014 00:10:42 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id s060AgJR077767; Mon, 6 Jan 2014 00:10:42 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id s060AgXk077766; Mon, 6 Jan 2014 00:10:42 GMT (envelope-from linimon) Date: Mon, 6 Jan 2014 00:10:42 GMT Message-Id: <201401060010.s060AgXk077766@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/185496: [re] RTL8169 doesn't receive unicast ethernet packets unless in promiscuous mode X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 06 Jan 2014 00:10:43 -0000 Old Synopsis: RTL8169 doesn't receive unicast ethernet packets unless in promiscuous mode New Synopsis: [re] RTL8169 doesn't receive unicast ethernet packets unless in promiscuous mode Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Jan 6 00:09:22 UTC 2014 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=185496 From owner-freebsd-net@FreeBSD.ORG Mon Jan 6 11:06:51 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2DAD76FA for ; Mon, 6 Jan 2014 11:06:51 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 183AB1085 for ; Mon, 6 Jan 2014 11:06:51 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id s06B6pTe045311 for ; Mon, 6 Jan 2014 11:06:51 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id s06B6oZ0045309 for freebsd-net@FreeBSD.org; Mon, 6 Jan 2014 11:06:50 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 6 Jan 2014 11:06:50 GMT Message-Id: <201401061106.s06B6oZ0045309@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 Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 06 Jan 2014 11:06:51 -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/185496 net [re] RTL8169 doesn't receive unicast ethernet packets o kern/185427 net [igb] freebsd 8.4, 9.1 and 9.2 panic Double-Fault with o kern/185148 net [ip6] [patch] Cleanup ip6_mroute.c o kern/184311 net [bge] [panic] kernel panic with bge(4) on SunFire X210 o kern/184084 net [ral] kernel crash by ral (RT3090) o bin/183687 net [patch] route(8): route add -net 172.20 add wrong host o kern/183659 net [tcp] ]TCP stack lock contention with short-lived conn o conf/183407 net [rc.d] [patch] Routing restart returns non-zero exitco o kern/183391 net [oce] 10gigabit networking problems with Emulex OCE 11 o kern/183390 net [ixgbe] 10gigabit networking problems o kern/182917 net [igb] strange out traffic with igb interfaces o kern/182847 net [netinet6] [patch] Remove dead code o kern/182665 net [wlan] Kernel panic when creating second wlandev. o kern/182382 net [tcp] sysctl to set TCP CC method on BIG ENDIAN system o kern/182297 net [cm] ArcNet driver fails to detect the link address - o kern/182212 net [patch] [ng_mppc] ng_mppc(4) blocks on network errors o kern/181970 net [re] LAN Realtek® 8111G is not supported by re driver o kern/181931 net [vlan] [lagg] vlan over lagg over mlxen crashes the ke o kern/181823 net [ip6] [patch] make ipv6 mroute return same errror code o kern/181741 net [kernel] [patch] Packet loss when 'control' messages a o kern/181703 net [re] [patch] Fix Realtek 8111G Ethernet controller not o kern/181657 net [bpf] [patch] BPF_COP/BPF_COPX instruction reservation o kern/181257 net [bge] bge link status change o kern/181236 net [igb] igb driver unstable work o kern/181135 net [netmap] [patch] sys/dev/netmap patch for Linux compat o kern/181131 net [netmap] [patch] sys/dev/netmap memory allocation impr o kern/181006 net [run] [patch] mbuf leak in run(4) driver o kern/180893 net [if_ethersubr] [patch] Packets received with own LLADD o kern/180844 net [panic] [re] Intermittent panic (re driver?) o kern/180775 net [bxe] if_bxe driver broken with Broadcom BCM57711 card o kern/180722 net [bluetooth] bluetooth takes 30-50 attempts to pair to s kern/180468 net [request] LOCAL_PEERCRED support for PF_INET o kern/180065 net [netinet6] [patch] Multicast loopback to own host brok o kern/179926 net [lacp] [patch] active aggregator selection bug o kern/179824 net [ixgbe] System (9.1-p4) hangs on heavy ixgbe network t o kern/179733 net [lagg] [patch] interface loses capabilities when proto o kern/179429 net [tap] STP enabled tap bridge o kern/179299 net [igb] Intel X540-T2 - unstable driver a kern/179264 net [vimage] [pf] Core dump with Packet filter and VIMAGE o kern/178947 net [arp] arp rejecting not working o kern/178782 net [ixgbe] 82599EB SFP does not work with passthrough und o kern/178612 net [run] kernel panic due the problems with run driver o kern/178472 net [ip6] [patch] make return code consistent with IPv4 co o kern/178079 net [tcp] Switching TCP CC algorithm panics on sparc64 wit s kern/178071 net FreeBSD unable to recongize Kontron (Industrial Comput o kern/177905 net [xl] [panic] ifmedia_set when pluging CardBus LAN card o kern/177618 net [bridge] Problem with bridge firewall with trunk ports o kern/177402 net [igb] [pf] problem with ethernet driver igb + pf / alt o kern/177400 net [jme] JMC25x 1000baseT establishment issues o kern/177366 net [ieee80211] negative malloc(9) statistics for 80211nod f kern/177362 net [netinet] [patch] Wrong control used to return TOS o kern/177194 net [netgraph] Unnamed netgraph nodes for vlan interfaces o kern/177184 net [bge] [patch] enable wake on lan o kern/177139 net [igb] igb drops ethernet ports 2 and 3 o kern/176884 net [re] re0 flapping up/down o kern/176671 net [epair] MAC address for epair device not unique o kern/176484 net [ipsec] [enc] [patch] panic: IPsec + enc(4); device na o kern/176446 net [netinet] [patch] Concurrency in ixgbe driving out-of- o kern/176420 net [kernel] [patch] incorrect errno for LOCAL_PEERCRED o kern/176419 net [kernel] [patch] socketpair support for LOCAL_PEERCRED o kern/176401 net [netgraph] page fault in netgraph o kern/176167 net [ipsec][lagg] using lagg and ipsec causes immediate pa o kern/176027 net [em] [patch] flow control systcl consistency for em dr o kern/176026 net [tcp] [patch] TCP wrappers caused quite a lot of warni o kern/175864 net [re] Intel MB D510MO, onboard ethernet not working aft o kern/175852 net [amd64] [patch] in_cksum_hdr() behaves differently on o kern/175734 net no ethernet detected on system with EG20T PCH chipset o kern/175267 net [pf] [tap] pf + tap keep state problem o kern/175236 net [epair] [gif] epair and gif Devices On Bridge o kern/175182 net [panic] kernel panic on RADIX_MPATH when deleting rout o kern/175153 net [tcp] will there miss a FIN when do TSO? o kern/174959 net [net] [patch] rnh_walktree_from visits spurious nodes o kern/174958 net [net] [patch] rnh_walktree_from makes unreasonable ass o kern/174897 net [route] Interface routes are broken o kern/174851 net [bxe] [patch] UDP checksum offload is wrong in bxe dri o kern/174850 net [bxe] [patch] bxe driver does not receive multicasts o kern/174849 net [bxe] [patch] bxe driver can hang kernel when reset o kern/174822 net [tcp] Page fault in tcp_discardcb under high traffic o kern/174602 net [gif] [ipsec] traceroute issue on gif tunnel with ipse o kern/174535 net [tcp] TCP fast retransmit feature works strange o kern/173871 net [gif] process of 'ifconfig gif0 create hangs' when if_ o kern/173475 net [tun] tun(4) stays opened by PID after process is term o kern/173201 net [ixgbe] [patch] Missing / broken ixgbe sysctl's and tu o kern/173137 net [em] em(4) unable to run at gigabit with 9.1-RC2 o kern/173002 net [patch] data type size problem in if_spppsubr.c o kern/172895 net [ixgb] [ixgbe] do not properly determine link-state o kern/172683 net [ip6] Duplicate IPv6 Link Local Addresses o kern/172675 net [netinet] [patch] sysctl_tcp_hc_list (net.inet.tcp.hos p kern/172113 net [panic] [e1000] [patch] 9.1-RC1/amd64 panices in igb(4 o kern/171840 net [ip6] IPv6 packets transmitting only on queue 0 o kern/171739 net [bce] [panic] bce related kernel panic o kern/171711 net [dummynet] [panic] Kernel panic in dummynet o kern/171532 net [ndis] ndis(4) driver includes 'pccard'-specific code, o kern/171531 net [ndis] undocumented dependency for ndis(4) o kern/171524 net [ipmi] ipmi driver crashes kernel by reboot or shutdow s kern/171508 net [epair] [request] Add the ability to name epair device o kern/171228 net [re] [patch] if_re - eeprom write issues o kern/170701 net [ppp] killl ppp or reboot with active ppp connection c o kern/170267 net [ixgbe] IXGBE_LE32_TO_CPUS is probably an unintentiona o kern/170081 net [fxp] pf/nat/jails not working if checksum offloading o kern/169898 net ifconfig(8) fails to set MTU on multiple interfaces. o kern/169676 net [bge] [hang] system hangs, fully or partially after re o kern/169620 net [ng] [pf] ng_l2tp incoming packet bypass pf firewall o kern/169459 net [ppp] umodem/ppp/3g stopped working after update from o kern/169438 net [ipsec] ipv4-in-ipv6 tunnel mode IPsec does not work p kern/168294 net [ixgbe] [patch] ixgbe driver compiled in kernel has no o kern/168246 net [em] Multiple em(4) not working with qemu o kern/168245 net [arp] [regression] Permanent ARP entry not deleted on o kern/168244 net [arp] [regression] Unable to manually remove permanent o kern/168183 net [bce] bce driver hang system o kern/167603 net [ip] IP fragment reassembly's broken: file transfer ov o kern/167500 net [em] [panic] Kernel panics in em driver o kern/167325 net [netinet] [patch] sosend sometimes return EINVAL with o kern/167202 net [igmp]: Sending multiple IGMP packets crashes kernel o kern/166462 net [gre] gre(4) when using a tunnel source address from c o kern/166285 net [arp] FreeBSD v8.1 REL p8 arp: unknown hardware addres o kern/166255 net [net] [patch] It should be possible to disable "promis p kern/165903 net mbuf leak o kern/165622 net [ndis][panic][patch] Unregistered use of FPU in kernel s kern/165562 net [request] add support for Intel i350 in FreeBSD 7.4 o kern/165526 net [bxe] UDP packets checksum calculation whithin if_bxe o kern/165488 net [ppp] [panic] Fatal trap 12 jails and ppp , kernel wit o kern/165305 net [ip6] [request] Feature parity between IP_TOS and IPV6 o kern/165296 net [vlan] [patch] Fix EVL_APPLY_VLID, update EVL_APPLY_PR o kern/165181 net [igb] igb freezes after about 2 weeks of uptime o kern/165174 net [patch] [tap] allow tap(4) to keep its address on clos o kern/165152 net [ip6] Does not work through the issue of ipv6 addresse o kern/164495 net [igb] connect double head igb to switch cause system t o kern/164490 net [pfil] Incorrect IP checksum on pfil pass from ip_outp o kern/164475 net [gre] gre misses RUNNING flag after a reboot o kern/164265 net [netinet] [patch] tcp_lro_rx computes wrong checksum i o kern/163903 net [igb] "igb0:tx(0)","bpf interface lock" v2.2.5 9-STABL o kern/163481 net freebsd do not add itself to ping route packet o kern/162927 net [tun] Modem-PPP error ppp[1538]: tun0: Phase: Clearing o kern/162558 net [dummynet] [panic] seldom dummynet panics o kern/162153 net [em] intel em driver 7.2.4 don't compile o kern/162110 net [igb] [panic] RELENG_9 panics on boot in IGB driver - o kern/162028 net [ixgbe] [patch] misplaced #endif in ixgbe.c o kern/161277 net [em] [patch] BMC cannot receive IPMI traffic after loa o kern/160873 net [igb] igb(4) from HEAD fails to build on 7-STABLE o kern/160750 net Intel PRO/1000 connection breaks under load until rebo o kern/160693 net [gif] [em] Multicast packet are not passed from GIF0 t o kern/160293 net [ieee80211] ppanic] kernel panic during network setup o kern/160206 net [gif] gifX stops working after a while (IPv6 tunnel) o kern/159817 net [udp] write UDPv4: No buffer space available (code=55) o kern/159629 net [ipsec] [panic] kernel panic with IPsec in transport m o kern/159621 net [tcp] [panic] panic: soabort: so_count o kern/159603 net [netinet] [patch] in_ifscrubprefix() - network route c o kern/159601 net [netinet] [patch] in_scrubprefix() - loopback route re o kern/159294 net [em] em watchdog timeouts o kern/159203 net [wpi] Intel 3945ABG Wireless LAN not support IBSS o kern/158930 net [bpf] BPF element leak in ifp->bpf_if->bif_dlist o kern/158726 net [ip6] [patch] ICMPv6 Router Announcement flooding limi o kern/158694 net [ix] [lagg] ix0 is not working within lagg(4) o kern/158665 net [ip6] [panic] kernel pagefault in in6_setscope() o kern/158635 net [em] TSO breaks BPF packet captures with em driver f kern/157802 net [dummynet] [panic] kernel panic in dummynet o kern/157785 net amd64 + jail + ipfw + natd = very slow outbound traffi o kern/157418 net [em] em driver lockup during boot on Supermicro X9SCM- o kern/157410 net [ip6] IPv6 Router Advertisements Cause Excessive CPU U o kern/157287 net [re] [panic] INVARIANTS panic (Memory modified after f o kern/157200 net [network.subr] [patch] stf(4) can not communicate betw o kern/157182 net [lagg] lagg interface not working together with epair o kern/156877 net [dummynet] [panic] dummynet move_pkt() null ptr derefe o kern/156667 net [em] em0 fails to init on CURRENT after March 17 o kern/156408 net [vlan] Routing failure when using VLANs vs. Physical e o kern/156328 net [icmp]: host can ping other subnet but no have IP from o kern/156317 net [ip6] Wrong order of IPv6 NS DAD/MLD Report o kern/156279 net [if_bridge][divert][ipfw] unable to correctly re-injec o kern/156226 net [lagg]: failover does not announce the failover to swi o kern/156030 net [ip6] [panic] Crash in nd6_dad_start() due to null ptr o kern/155680 net [multicast] problems with multicast s kern/155642 net [new driver] [request] Add driver for Realtek RTL8191S o kern/155597 net [panic] Kernel panics with "sbdrop" message o kern/155420 net [vlan] adding vlan break existent vlan o kern/155177 net [route] [panic] Panic when inject routes in kernel o kern/155010 net [msk] ntfs-3g via iscsi using msk driver cause kernel o kern/154943 net [gif] ifconfig gifX create on existing gifX clears IP s kern/154851 net [new driver] [request]: Port brcm80211 driver from Lin o kern/154850 net [netgraph] [patch] ng_ether fails to name nodes when t o kern/154679 net [em] Fatal trap 12: "em1 taskq" only at startup (8.1-R o kern/154600 net [tcp] [panic] Random kernel panics on tcp_output o kern/154557 net [tcp] Freeze tcp-session of the clients, if in the gat o kern/154443 net [if_bridge] Kernel module bridgestp.ko missing after u o kern/154286 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/154255 net [nfs] NFS not responding o kern/154214 net [stf] [panic] Panic when creating stf interface o kern/154185 net race condition in mb_dupcl p kern/154169 net [multicast] [ip6] Node Information Query multicast add o kern/154134 net [ip6] stuck kernel state in LISTEN on ipv6 daemon whic o kern/154091 net [netgraph] [panic] netgraph, unaligned mbuf? o conf/154062 net [vlan] [patch] change to way of auto-generatation of v o kern/153937 net [ral] ralink panics the system (amd64 freeBSDD 8.X) wh o kern/153936 net [ixgbe] [patch] MPRC workaround incorrectly applied to o kern/153816 net [ixgbe] ixgbe doesn't work properly with the Intel 10g o kern/153772 net [ixgbe] [patch] sysctls reference wrong XON/XOFF varia o kern/153497 net [netgraph] netgraph panic due to race conditions o kern/153454 net [patch] [wlan] [urtw] Support ad-hoc and hostap modes o kern/153308 net [em] em interface use 100% cpu o kern/153244 net [em] em(4) fails to send UDP to port 0xffff o kern/152893 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/152853 net [em] tftpd (and likely other udp traffic) fails over e o kern/152828 net [em] poor performance on 8.1, 8.2-PRE o kern/152569 net [net]: Multiple ppp connections and routing table prob o kern/152235 net [arp] Permanent local ARP entries are not properly upd o kern/152141 net [vlan] [patch] encapsulate vlan in ng_ether before out o kern/152036 net [libc] getifaddrs(3) returns truncated sockaddrs for n o kern/151690 net [ep] network connectivity won't work until dhclient is o kern/151681 net [nfs] NFS mount via IPv6 leads to hang on client with o kern/151593 net [igb] [panic] Kernel panic when bringing up igb networ o kern/150920 net [ixgbe][igb] Panic when packets are dropped with heade o kern/150557 net [igb] igb0: Watchdog timeout -- resetting o kern/150251 net [patch] [ixgbe] Late cable insertion broken o kern/150249 net [ixgbe] Media type detection broken o bin/150224 net ppp(8) does not reassign static IP after kill -KILL co f kern/149969 net [wlan] [ral] ralink rt2661 fails to maintain connectio o kern/149643 net [rum] device not sending proper beacon frames in ap mo o kern/149609 net [panic] reboot after adding second default route o kern/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148018 net [flowtable] flowtable crashes on ia64 o kern/147912 net [boot] FreeBSD 8 Beta won't boot on Thinkpad i1300 11 o kern/147894 net [ipsec] IPv6-in-IPv4 does not work inside an ESP-only o kern/147155 net [ip6] setfb not work with ipv6 o kern/146845 net [libc] close(2) returns error 54 (connection reset by f kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146534 net [icmp6] wrong source address in echo reply o kern/146427 net [mwl] Additional virtual access points don't work on m f kern/146394 net [vlan] IP source address for outgoing connections o bin/146377 net [ppp] [tun] Interface doesn't clear addresses when PPP o kern/146358 net [vlan] wrong destination MAC address o kern/146165 net [wlan] [panic] Setting bssid in adhoc mode causes pani o kern/146037 net [panic] mpd + CoA = kernel panic o kern/145825 net [panic] panic: soabort: so_count o kern/145728 net [lagg] Stops working lagg between two servers. p kern/145600 net TCP/ECN behaves different to CE/CWR than ns2 reference f kern/144917 net [flowtable] [panic] flowtable crashes system [regressi o kern/144882 net MacBookPro =>4.1 does not connect to BSD in hostap wit o kern/144874 net [if_bridge] [patch] if_bridge frees mbuf after pfil ho o conf/144700 net [rc.d] async dhclient breaks stuff for too many people o kern/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/144231 net bind/connect/sendto too strict about sockaddr length o kern/143846 net [gif] bringing gif3 tunnel down causes gif0 tunnel to s kern/143673 net [stf] [request] there should be a way to support multi o kern/143622 net [pfil] [patch] unlock pfil lock while calling firewall o kern/143593 net [ipsec] When using IPSec, tcpdump doesn't show outgoin o kern/143591 net [ral] RT2561C-based DLink card (DWL-510) fails to work o kern/143208 net [ipsec] [gif] IPSec over gif interface not working o kern/143034 net [panic] system reboots itself in tcp code [regression] o kern/142877 net [hang] network-related repeatable 8.0-STABLE hard hang o kern/142774 net Problem with outgoing connections on interface with mu o kern/142772 net [libc] lla_lookup: new lle malloc failed f kern/142518 net [em] [lagg] Problem on 8.0-STABLE with em and lagg o kern/142018 net [iwi] [patch] Possibly wrong interpretation of beacon- o kern/141861 net [wi] data garbled with WEP and wi(4) with Prism 2.5 f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140682 net [netgraph] [panic] random panic in netgraph f kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL p kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 o kern/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR if_adata/ o kern/138266 net [panic] kernel panic when udp benchmark test used as r f kern/138029 net [bpf] [panic] periodically kernel panic and reboot o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 p bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133736 net [udp] ip_id not protected ... o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o conf/132851 net [patch] rc.conf(5): allow to setfib(1) for service run o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o 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 kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow f kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o bin/128954 net ifconfig(8) deletes valid routes o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by p kern/127360 net [socket] TOE socket options missing from sosetopt() o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126339 net [ipw] ipw driver drops the connection o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124225 net [ndis] [patch] ndis network driver sometimes loses net o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123758 net [panic] panic while restarting net/freenet6 o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work 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/121534 net [ipl] [nat] FreeBSD Release 6.3 Kernel Trap 12: o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] [security] ppp(8): fix local stack overflow in o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/120966 net [rum] kernel panic with if_rum and WPA encryption o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/118727 net [netgraph] [patch] [request] add new ng_pf module o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111537 net [inet6] [patch] ip6_input() treats mbuf cluster wrong o kern/111457 net [ral] ral(4) freeze o kern/110284 net [if_ethersubr] Invalid Assumption in SIOCSIFADDR in et o kern/110249 net [kernel] [regression] [patch] setsockopt() error regre o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] f kern/108197 net [panic] [gif] [ip6] if_delmulti reference counting pan o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106444 net [netgraph] [panic] Kernel Panic on Binding to an ip to o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/104738 net [inet] [patch] Reentrant problem with inet_ntoa in the 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/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working o kern/97306 net [netgraph] NG_L2TP locks after connection with failed o conf/97014 net [gif] gifconfig_gif? in rc.conf does not recognize IPv f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/87421 net [netgraph] [panic]: ng_ether + ng_eiface + if_bridge o kern/86871 net [tcp] [patch] allocation logic for PCBs in TIME_WAIT s o kern/86427 net [lor] Deadlock with FASTIPSEC and nat o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ o bin/82975 net route change does not parse classfull network as given o kern/82881 net [netgraph] [panic] ng_fec(4) causes kernel panic after o kern/82468 net Using 64MB tcp send/recv buffers, trafficflow stops, i o bin/82185 net [patch] ndp(8) can delete the incorrect entry o kern/81095 net IPsec connection stops working if associated network i o kern/78968 net FreeBSD freezes on mbufs exhaustion (network interface o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o kern/77341 net [ip6] problems with IPV6 implementation 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/68889 net [panic] m_copym, length > size of mbuf chain o kern/66225 net [netgraph] [patch] extend ng_eiface(4) control message o kern/65616 net IPSEC can't detunnel GRE packets after real ESP encryp s kern/60293 net [patch] FreeBSD arp poison patch a kern/56233 net IPsec tunnel (ESP) over IPv6: MTU computation is wrong s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/31940 net ip queue length too short for >500kpps o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna f kern/24959 net [patch] proper TCP_NOPUSH/TCP_CORK compatibility o conf/23063 net [arp] [patch] for static ARP tables in rc.network o kern/21998 net [socket] [patch] ident only for outgoing connections o kern/5877 net [socket] sb_cc counts control data as well as data dat 474 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Jan 6 23:23:24 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 25C2C491 for ; Mon, 6 Jan 2014 23:23:24 +0000 (UTC) Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E852415E0 for ; Mon, 6 Jan 2014 23:23:23 +0000 (UTC) Received: by mail-pd0-f178.google.com with SMTP id y10so18684231pdj.23 for ; Mon, 06 Jan 2014 15:23:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=2ax5x2Bojv+1eeK7dGoDy0pYiEP75WJvNXtDKzJPDh0=; b=mM+s32oPcW44TXfNMet58nPesGvl2OpP6SW5FfOx2f4GEOc7DFM43kJNv8L3QNnyCL vAFzNvfxhmTmNfMYu21AtLG8gzbKdoha64cHjREptTkoCrCrmMHPyEDUl10cLFL5eh4r kjOF5kKDkFh1oyXSDWcgBGh3BPAizaOG0Xe14= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=2ax5x2Bojv+1eeK7dGoDy0pYiEP75WJvNXtDKzJPDh0=; b=aS0NsFi6fY/FVgXrvP+wf3oYVPeDLEYkzDMJcLYFWJXFCIGJZn61SoooF9kvDHyKwk ayK+em2Ab8xdVDSwhvnqxKrotrb1If9PYUv8Ibk8J+mJ+QfjySben90BSS08L6saK3Q5 D790Pw5uoRdlLFCaiNCUzimNRv/pbrWlJcgbTSkZeWxHtW72QvVDiZyUJ7Ftql2j2ecc i9+wHvWoXROFPKw5qMRAkknCG3YbeGBI7NDuf5B01fy0qQ1sjHSW4LaUuo469a+29BPo djBw0yqcYcu80QFQK9r6mQxsJqrpgrurTnZjSoez7ja1GmlrTqSphCs8UwfgbXsdkaAc FyaA== X-Gm-Message-State: ALoCoQk/CLMsz48fpu6uZsS6A5XR3h92quer6X1auvumWXlYcgqGBowOCvgNrpKP0ywj3mMeHKwv X-Received: by 10.67.14.162 with SMTP id fh2mr1215560pad.120.1389050603567; Mon, 06 Jan 2014 15:23:23 -0800 (PST) Received: from hater-dm.corp.yahoo.com (nat-dip4.cfw-a-gci.corp.yahoo.com. [209.131.62.113]) by mx.google.com with ESMTPSA id vn10sm131362464pbc.21.2014.01.06.15.23.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 06 Jan 2014 15:23:22 -0800 (PST) Message-ID: <52CB3AE9.3030107@wemm.org> Date: Mon, 06 Jan 2014 15:23:21 -0800 From: Peter Wemm User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: TCP question: Is this simultaneous close handling broken? X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 06 Jan 2014 23:23:24 -0000 We've hit a weird problem at work when dealing with simultaneous closes. In this particular case, it's a FreeBSD-7.4 machine talking some random Linux host. There is a client/server protocol in use, and both ends are doing a close at the same time. It might be a shutdown, I haven't seen all the code yet. A convenient summary of how a simultaneous close is performed: "A simultaneous CLOSE by users at both ends of a connection causes FIN segments to be exchanged. When all segments preceding the FINs have been processed and acknowledged, each TCP can ACK the FIN it has received." A packet capture, with relative timestamps: 000050 freebsd.28411 > linux.14001: F 6486:6486(0) ack 232 000031 linux.14001 > freebsd.28411: F 232:232(0) ack 6486 000333 linux.14001 > freebsd.28411: . ack 6487 [200ms retransmit timer fires on linux] 200490 linux.14001 > freebsd.28411: F 232:232(0) ack 6487 000011 freebsd.28411 > linux.14001: . ack 233 I am not familar with the finer details of edge cases of TCP/IP like this, but this looks a bit odd to me. What am I looking at? Who's at fault? It looks like we're failing to recognize the ack for our fin. The quote above from some google search result: http://www.freesoft.org/CIE/Course/Section4/11.htm Insight would be greatly appreciated... -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV UTF-8: for when a ' just won\342\200\231t do. From owner-freebsd-net@FreeBSD.ORG Tue Jan 7 02:53:19 2014 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 243F21B0; Tue, 7 Jan 2014 02:53:19 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EC3D816C5; Tue, 7 Jan 2014 02:53:18 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id s072rIfq076048; Tue, 7 Jan 2014 02:53:18 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id s072rIVP076047; Tue, 7 Jan 2014 02:53:18 GMT (envelope-from linimon) Date: Tue, 7 Jan 2014 02:53:18 GMT Message-Id: <201401070253.s072rIVP076047@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/185022: [tun] ls /dev/tun creates tun interface X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 07 Jan 2014 02:53:19 -0000 Old Synopsis: ls /dev/tun creates tun interface New Synopsis: [tun] ls /dev/tun creates tun interface Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Tue Jan 7 02:53:06 UTC 2014 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=185022 From owner-freebsd-net@FreeBSD.ORG Tue Jan 7 02:53:35 2014 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9386628C; Tue, 7 Jan 2014 02:53:35 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 67ABE16D5; Tue, 7 Jan 2014 02:53:35 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id s072rZ2h076098; Tue, 7 Jan 2014 02:53:35 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id s072rZmB076097; Tue, 7 Jan 2014 02:53:35 GMT (envelope-from linimon) Date: Tue, 7 Jan 2014 02:53:35 GMT Message-Id: <201401070253.s072rZmB076097@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/185023: [tun] Closing tun interface deconfigures IP address X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 07 Jan 2014 02:53:35 -0000 Old Synopsis: Closing tun interface deconfigures IP address New Synopsis: [tun] Closing tun interface deconfigures IP address Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Tue Jan 7 02:53:21 UTC 2014 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=185023 From owner-freebsd-net@FreeBSD.ORG Tue Jan 7 20:10:25 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C3FF5598 for ; Tue, 7 Jan 2014 20:10:25 +0000 (UTC) Received: from mail-gg0-x22c.google.com (mail-gg0-x22c.google.com [IPv6:2607:f8b0:4002:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 779AF1953 for ; Tue, 7 Jan 2014 20:10:25 +0000 (UTC) Received: by mail-gg0-f172.google.com with SMTP id q6so114720ggc.17 for ; Tue, 07 Jan 2014 12:10:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=N3moCUjvSszeiWQGRdyBkwIBQdB0r66vr2/CytyYTxM=; b=Pl2H8ldZ8bAZ4QcyZJSUi/9Dsjj1ITZOtvRXbIewJq85gJaCqMXfELZsypjcZ2zRvC bD4M8Q3FKJYLyYUlL/as8d4pwHw7AHIF9+Mn0mNBULIX4QmIJ6HH/9rnC48DW1IUNUND LSdGmgodhGR0RTuDEWRW7H+TDMi1+b2Duv4Ww= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:organization:user-agent :mime-version:to:subject:references:in-reply-to:content-type; bh=N3moCUjvSszeiWQGRdyBkwIBQdB0r66vr2/CytyYTxM=; b=AtHMoOooV45BNOXH68t0Wi4n8od0eZxlSCEg/6k57uSx57cuUxkT98RQT+kfNl5Xnz K9J7HimAohpxqUa2vYyOD4jteKLn2Q3llB5GpTmPsZIv4ClWZxIuE0p4smTcjBWasdEC LAdmEVEZ9fxXiJWAOEb0ld3cUt75Yi7h9SKADPVV8tM2XMpWdDzbwKAoBFf8K6aMKBtH Gn4d4Xr/VePjp0U5aZZeSRYwPxMFdB87b10/tlI0bQw+1hTVwc13URIVt8hV3CkXhUBH mF2tTCm9+EXEUZGtDK604p+tS7SslXSeHeNOTAVGeNPpXlcIZV98q+y75stExgC/UPGB Mq2A== X-Gm-Message-State: ALoCoQkGP1F/o5HLdZkQFOKAiZAP3l06+ruhRsPByHJex+nGby3GMvCEnKVoKM3s4ey3kmmXyJY2 X-Received: by 10.236.74.73 with SMTP id w49mr3860511yhd.87.1389125424518; Tue, 07 Jan 2014 12:10:24 -0800 (PST) Received: from hackintosh.wemm.org ([2601:9:e80:770:69a1:2b30:eab6:4149]) by mx.google.com with ESMTPSA id b30sm25508942yhm.5.2014.01.07.12.10.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 07 Jan 2014 12:10:23 -0800 (PST) Message-ID: <52CC5F2E.5030201@wemm.org> Date: Tue, 07 Jan 2014 12:10:22 -0800 From: Peter Wemm Organization: World Domination in progress. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: TCP question: Is this simultaneous close handling broken? References: <52CB3AE9.3030107@wemm.org> In-Reply-To: <52CB3AE9.3030107@wemm.org> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KcbDav8DVDNlExS7ASDrFxMrBqUjICjGW" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 07 Jan 2014 20:10:25 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --KcbDav8DVDNlExS7ASDrFxMrBqUjICjGW Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 1/6/14, 3:23 PM, Peter Wemm wrote: > We've hit a weird problem at work when dealing with simultaneous closes= =2E > In this particular case, it's a FreeBSD-7.4 machine talking some random= > Linux host. >=20 > There is a client/server protocol in use, and both ends are doing a clo= se > at the same time. It might be a shutdown, I haven't seen all the code = yet. [..] > A packet capture, with relative timestamps: >=20 > 000050 freebsd.28411 > linux.14001: F 6486:6486(0) ack 232 > 000031 linux.14001 > freebsd.28411: F 232:232(0) ack 6486 > 000333 linux.14001 > freebsd.28411: . ack 6487 > [200ms retransmit timer fires on linux] > 200490 linux.14001 > freebsd.28411: F 232:232(0) ack 6487 > 000011 freebsd.28411 > linux.14001: . ack 233 [..] > What am I looking at? Who's at fault? It looks like we're failing to > recognize the ack for our fin. It definitely looks like FreeBSD at fault. We've simply not acked their = FIN until they retransmitted it. I've looked at the commit logs and I don't see anything obvious that stan= ds out to me for a fix for this. Most of the changes seem to be lock struct= ure changes than protocol fixes. I see things like ECN and other protocol features being added as well. Where should I look in the code? --=20 Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6F= JV UTF-8: for when a ' just won\342\200\231t do. --KcbDav8DVDNlExS7ASDrFxMrBqUjICjGW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLMXy4ACgkQFRKuUnJ3cX88nQCeLUtlGDcxkTWs9+bQoEm3sXJz Ay4AmwfEOyuOKCHgPl3Y4JfctaZDNIvx =T93F -----END PGP SIGNATURE----- --KcbDav8DVDNlExS7ASDrFxMrBqUjICjGW-- From owner-freebsd-net@FreeBSD.ORG Tue Jan 7 20:45:10 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 366F6348 for ; Tue, 7 Jan 2014 20:45:10 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 11E921CD4 for ; Tue, 7 Jan 2014 20:45:09 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s07Kj8mn017791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Jan 2014 12:45:09 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s07Kj8wR017790; Tue, 7 Jan 2014 12:45:08 -0800 (PST) (envelope-from jmg) Date: Tue, 7 Jan 2014 12:45:08 -0800 From: John-Mark Gurney To: Peter Wemm Subject: Re: TCP question: Is this simultaneous close handling broken? Message-ID: <20140107204508.GS99167@funkthat.com> Mail-Followup-To: Peter Wemm , freebsd-net@freebsd.org References: <52CB3AE9.3030107@wemm.org> <52CC5F2E.5030201@wemm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52CC5F2E.5030201@wemm.org> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Tue, 07 Jan 2014 12:45:09 -0800 (PST) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 07 Jan 2014 20:45:10 -0000 Peter Wemm wrote this message on Tue, Jan 07, 2014 at 12:10 -0800: > On 1/6/14, 3:23 PM, Peter Wemm wrote: > > We've hit a weird problem at work when dealing with simultaneous closes. > > In this particular case, it's a FreeBSD-7.4 machine talking some random > > Linux host. > > > > There is a client/server protocol in use, and both ends are doing a close > > at the same time. It might be a shutdown, I haven't seen all the code yet. > [..] > > A packet capture, with relative timestamps: > > > > 000050 freebsd.28411 > linux.14001: F 6486:6486(0) ack 232 > > 000031 linux.14001 > freebsd.28411: F 232:232(0) ack 6486 > > 000333 linux.14001 > freebsd.28411: . ack 6487 > > [200ms retransmit timer fires on linux] > > 200490 linux.14001 > freebsd.28411: F 232:232(0) ack 6487 > > 000011 freebsd.28411 > linux.14001: . ack 233 > [..] > > What am I looking at? Who's at fault? It looks like we're failing to > > recognize the ack for our fin. > > It definitely looks like FreeBSD at fault. We've simply not acked their FIN > until they retransmitted it. > > I've looked at the commit logs and I don't see anything obvious that stands > out to me for a fix for this. Most of the changes seem to be lock structure > changes than protocol fixes. I see things like ECN and other protocol > features being added as well. > > Where should I look in the code? I've been looking in tcp_input.c. When we send the FIN, we are in FIN_WAIT_1, and then upon receiving the FIN, we should transition to CLOSING. This happens in tcp_do_segment when we receive a packet w/ the _FIN bit set while in FIN_WAIT_1. The next question is if we are hitting this code (maybe a printf), why isn't the packet being sent out... Only a page or so down from this, you see: /* * Return any desired output. */ if (needoutput || (tp->t_flags & TF_ACKNOW)) (void) tcp_output(tp); And the only what TF_ACKNOW isn't set is if for some reason the TF_NEEDSYN flag is still set (from just above the previous code)... So, maybe a printf on the transition to _CLOSING to make sure it's hit, plus a print of t_flags at the same location to make sure _NEEDSYN isn't set would help us understand what is wrong... If we don't get the printf, then there is other weird stuff going on... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-net@FreeBSD.ORG Tue Jan 7 21:34:49 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CE3F2A83 for ; Tue, 7 Jan 2014 21:34:49 +0000 (UTC) Received: from hergotha.csail.mit.edu (wollman-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:ccb::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8B37010F7 for ; Tue, 7 Jan 2014 21:34:49 +0000 (UTC) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.7/8.14.7) with ESMTP id s07LYlkK066067 for ; Tue, 7 Jan 2014 16:34:47 -0500 (EST) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.7/8.14.4/Submit) id s07LYk8l066064; Tue, 7 Jan 2014 16:34:46 -0500 (EST) (envelope-from wollman) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21196.29430.733181.353677@hergotha.csail.mit.edu> Date: Tue, 7 Jan 2014 16:34:46 -0500 From: Garrett Wollman To: freebsd-net@freebsd.org Subject: ETHER_MAX_LEN_JUMBO X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (hergotha.csail.mit.edu [127.0.0.1]); Tue, 07 Jan 2014 16:34:47 -0500 (EST) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on hergotha.csail.mit.edu X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 07 Jan 2014 21:34:49 -0000 In , the constant ETHER_MAX_LEN_JUMBO is set to 9018. According to svn, this was added by sam back in 2002, and now seems a bit low. Our maximum MTU at work has always been 9120 (implying 9138 for ETHER_MAX_LEN_JUMBO), and we have hardware in production now that defaults to 12000. The ixgbe driver doesn't use this constant, bu the cxgbe driver does. Does anyone know a reason I should *not* increase it to a more reasonable level? (9216 would be my choice if we wanted to stick with values in the 9k range.) -GAWollman From owner-freebsd-net@FreeBSD.ORG Tue Jan 7 22:40:10 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 139B6E83 for ; Tue, 7 Jan 2014 22:40:10 +0000 (UTC) Received: from mail-gg0-x233.google.com (mail-gg0-x233.google.com [IPv6:2607:f8b0:4002:c02::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BA49916AF for ; Tue, 7 Jan 2014 22:40:09 +0000 (UTC) Received: by mail-gg0-f179.google.com with SMTP id l4so143971ggi.24 for ; Tue, 07 Jan 2014 14:40:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=MwJsFVu6uDbHcX8GSkvuGSEEKKRr8F/lNz2YDnjti74=; b=YeWbGovMPT6GOC2FWy8i/Hi/Lg3FYXgSdyYw5CD8lIQdfKBHdPViJQoxPXxTOUE5Ku IYI5rLbLQ3D6lyaf4pUHsuQnDtHzUVJUK+WOw/LaGimxLbZcCSR1sGzvjk5FTIb/QvLd 4EkUgFs7Fy9xruhxP05og8FJUhwjlKGPwmWec= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:organization:user-agent :mime-version:to:subject:references:in-reply-to:content-type; bh=MwJsFVu6uDbHcX8GSkvuGSEEKKRr8F/lNz2YDnjti74=; b=gnrEAK17Vjtk95/jZscf5QYgouBpY0sYxeZ/HHiIfD55AAm0VKZcAhtdFZ8Th3tPE6 4FuJ9NcJesGihpA3HrHznE+qrrgeTXI7eUHvjEbcKBhelGkgq6CmSGL9cGW5iAzuy12Q L9RtykyRc/NbtqlwwfyUxkuRTP0gz2HWubyMn/QgfMjN9kCHhor0YfQPIq4Eht5lX/AZ FHxlSQhb6zQQDrYKvnvZTevV47jNpYwxW7To5nKu62b6Nl6reh38OKEjAtmfvV0Tage0 0qkJDufdzIp0InE+bxwg3meaWrxdTzSwgrkRNYOvNToDZYHiC5yFH2T0YQdnCXPG/o+G mNHA== X-Gm-Message-State: ALoCoQliJnuRfNsc94svvl5zFb8lecuRKA+QYGw5/4k6t98lNVTjYtWEAdgis/lI9+YKUBr8Kvwq X-Received: by 10.236.147.107 with SMTP id s71mr14185703yhj.45.1389134408824; Tue, 07 Jan 2014 14:40:08 -0800 (PST) Received: from hackintosh.wemm.org ([2601:9:e80:770:69a1:2b30:eab6:4149]) by mx.google.com with ESMTPSA id m68sm25963808yhj.22.2014.01.07.14.40.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 07 Jan 2014 14:40:07 -0800 (PST) Message-ID: <52CC8246.7080609@wemm.org> Date: Tue, 07 Jan 2014 14:40:06 -0800 From: Peter Wemm Organization: World Domination in progress. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: TCP question: Is this simultaneous close handling broken? References: <52CB3AE9.3030107@wemm.org> <52CC5F2E.5030201@wemm.org> In-Reply-To: <52CC5F2E.5030201@wemm.org> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="THfFN3Oi0mROUh9xOcrEIPcW0LnguJ57W" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 07 Jan 2014 22:40:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --THfFN3Oi0mROUh9xOcrEIPcW0LnguJ57W Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 1/7/14, 12:10 PM, Peter Wemm wrote: > On 1/6/14, 3:23 PM, Peter Wemm wrote: >> We've hit a weird problem at work when dealing with simultaneous close= s. >> In this particular case, it's a FreeBSD-7.4 machine talking some rando= m >> Linux host. >> >> There is a client/server protocol in use, and both ends are doing a cl= ose >> at the same time. It might be a shutdown, I haven't seen all the code= yet. > [..] >> A packet capture, with relative timestamps: >> >> 000050 freebsd.28411 > linux.14001: F 6486:6486(0) ack 232 >> 000031 linux.14001 > freebsd.28411: F 232:232(0) ack 6486 >> 000333 linux.14001 > freebsd.28411: . ack 6487 >> [200ms retransmit timer fires on linux] >> 200490 linux.14001 > freebsd.28411: F 232:232(0) ack 6487 >> 000011 freebsd.28411 > linux.14001: . ack 233 > [..] >> What am I looking at? Who's at fault? It looks like we're failing to= >> recognize the ack for our fin. >=20 > It definitely looks like FreeBSD at fault. We've simply not acked thei= r FIN > until they retransmitted it. >=20 > I've looked at the commit logs and I don't see anything obvious that st= ands > out to me for a fix for this. Most of the changes seem to be lock stru= cture > changes than protocol fixes. I see things like ECN and other protocol > features being added as well. >=20 > Where should I look in the code? It turns out it's fixed in HEAD. ------------------------------------------------------------------------ r258821 | eadler | 2013-12-01 19:11:25 -0800 (Sun, 01 Dec 2013) | 14 line= s In a situation where: - The remote host sends a FIN - in an ACK for a sequence number for which an ACK has already been received - There is still unacked data on route to the remote host - The packet does not contain a window update The packet may be dropped without processing the FIN flag. PR: kern/99188 Submitted by: Staffan Ulfberg Discussed with: andre MFC after: never ------------------------------------------------------------------------ The bug in question is from Date: Mon, 19 Jun 2006 23:45:05 +0200 (CEST) This is the exact situation we hit. --=20 Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6F= JV UTF-8: for when a ' just won\342\200\231t do. --THfFN3Oi0mROUh9xOcrEIPcW0LnguJ57W Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLMgkYACgkQFRKuUnJ3cX/KuQCfV6gHtCN58vr6A+fpUsVPJ7YL jWIAn0itVXvDRhEGCH+zrsX5XO9rJNq/ =aWiN -----END PGP SIGNATURE----- --THfFN3Oi0mROUh9xOcrEIPcW0LnguJ57W-- From owner-freebsd-net@FreeBSD.ORG Tue Jan 7 23:40:04 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E19152BF; Tue, 7 Jan 2014 23:40:04 +0000 (UTC) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [IPv6:2607:f3e0:0:1::12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5DD241B45; Tue, 7 Jan 2014 23:40:04 +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.7/8.14.7) with ESMTP id s07Ne2oM074130; Tue, 7 Jan 2014 18:40:03 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <52CC903C.5090706@sentex.net> Date: Tue, 07 Jan 2014 18:39:40 -0500 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Peter Wemm , freebsd-net@freebsd.org, eadler@freebsd.org Subject: Re: TCP question: Is this simultaneous close handling broken? References: <52CB3AE9.3030107@wemm.org> <52CC5F2E.5030201@wemm.org> <52CC8246.7080609@wemm.org> In-Reply-To: <52CC8246.7080609@wemm.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.74 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 07 Jan 2014 23:40:05 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 1/7/2014 5:40 PM, Peter Wemm wrote: > The packet may be dropped without processing the FIN flag. > MFC after: never Hi, Are there any potential side effects to this fix ? The original author said they were not going to MFC due to possible regressions. I know you probably see more FreeBSD traffic then most at Y!, and so are very sensitive to this, but thought I would ask for clarification. ---Mike - -- - ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSzJA8AAoJEJXHwM2kc8rXYJUH/3Hb7Yh7Lv/sAEjRjN5gN9id C9B6OlBY3NWfSVYTFngBzqcePuxsGXD4gELA1QQuGa4B2/dYgu62u0+zDdfCyVGx 7WVQlsrg2To9y8Z4SCZ3vCHJ20GxTNtCJEcySldcvCl8Z2Xn2cIk0BQmi5n7icVx z0ZIcWBTCNskfcLI6jHNFZ6dslRQy3xyleOpp1heQUyaVpfMRNZvOfoL1hnEnS9H FpnhIdFSKJ48b9Vw4Xql62A+LfCUHHa/Ey8rjEp5K90FTByPcNaDiVddNHZmBVAO lTmOobA2zsFzSh3fgnXikjCS4MA+3rTKHscduihk4vf6AIKLWx00h4Bp0n7AGoY= =+cGv -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Wed Jan 8 00:50:17 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7BAF056F for ; Wed, 8 Jan 2014 00:50:17 +0000 (UTC) Received: from mail.lhr1.as41113.net (mail.lhr1.as41113.net [91.208.177.22]) by mx1.freebsd.org (Postfix) with ESMTP id 43412116F for ; Wed, 8 Jan 2014 00:50:16 +0000 (UTC) Received: from [172.16.10.171] (unknown [91.208.177.70]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lhr1.as41113.net (Postfix) with ESMTPS id 3dzWrH3WFPz7vbZ; Wed, 8 Jan 2014 00:42:23 +0000 (UTC) Message-ID: <52CC9EF0.5010504@rewt.org.uk> Date: Wed, 08 Jan 2014 00:42:24 +0000 From: Joe Holden User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Garrett Wollman , freebsd-net@freebsd.org Subject: Re: ETHER_MAX_LEN_JUMBO References: <21196.29430.733181.353677@hergotha.csail.mit.edu> In-Reply-To: <21196.29430.733181.353677@hergotha.csail.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 08 Jan 2014 00:50:17 -0000 16k frames are available on commidity intel cards so perhaps a bump to 16k should be enough for the foreseeable future, although saying that there is nothing to stop another big leap in frame sizes. We should probably be ahead of the curve here, rather than playing catch up with vendors. Would it be possible to limit the max size by looking at drivers in the tree at compile-time, perhaps have them declare the max frame size the supported hardware can handle? On 07/01/2014 21:34, Garrett Wollman wrote: > In , the constant ETHER_MAX_LEN_JUMBO is set to 9018. > According to svn, this was added by sam back in 2002, and now seems a > bit low. Our maximum MTU at work has always been 9120 (implying 9138 > for ETHER_MAX_LEN_JUMBO), and we have hardware in production now that > defaults to 12000. The ixgbe driver doesn't use this constant, bu > the cxgbe driver does. Does anyone know a reason I should *not* > increase it to a more reasonable level? (9216 would be my choice if > we wanted to stick with values in the 9k range.) > > -GAWollman > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Wed Jan 8 01:22:32 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6D450C84 for ; Wed, 8 Jan 2014 01:22:32 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 439EE13BD for ; Wed, 8 Jan 2014 01:22:31 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s081MG9M021594 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Jan 2014 17:22:17 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s081MFso021593; Tue, 7 Jan 2014 17:22:15 -0800 (PST) (envelope-from jmg) Date: Tue, 7 Jan 2014 17:22:15 -0800 From: John-Mark Gurney To: Joe Holden Subject: Re: ETHER_MAX_LEN_JUMBO Message-ID: <20140108012215.GV99167@funkthat.com> Mail-Followup-To: Joe Holden , Garrett Wollman , freebsd-net@freebsd.org References: <21196.29430.733181.353677@hergotha.csail.mit.edu> <52CC9EF0.5010504@rewt.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52CC9EF0.5010504@rewt.org.uk> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Tue, 07 Jan 2014 17:22:17 -0800 (PST) Cc: freebsd-net@freebsd.org, Garrett Wollman X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 08 Jan 2014 01:22:32 -0000 Joe Holden wrote this message on Wed, Jan 08, 2014 at 00:42 +0000: > 16k frames are available on commidity intel cards so perhaps a bump to > 16k should be enough for the foreseeable future, although saying that > there is nothing to stop another big leap in frame sizes. > > We should probably be ahead of the curve here, rather than playing catch > up with vendors. Would it be possible to limit the max size by looking > at drivers in the tree at compile-time, perhaps have them declare the > max frame size the supported hardware can handle? Why do we even need this define? atse uses it to create a buffer so it doesn't have to deal w/ data being split between mbufs... why they didn't use m_copydata + the ofset, I don't know, but shouldn't be hard to fix the driver.. cas uses it instead of reading what the interface MTU is when programming the max length of a frame... ng_eiface just uses it to limit how large you can set your MTU... It is used to define ETHERMTU_JUMBO, which is used by a few drivers (cas, cxgb, cxgbe and mxge) to either set the default mtu, or limit how large the MTU can be set to... I would say we should just remove these defines... If a card has an MTU limit, let it define it's own, not use some fake limit by the rest of the system... > On 07/01/2014 21:34, Garrett Wollman wrote: > >In , the constant ETHER_MAX_LEN_JUMBO is set to 9018. > >According to svn, this was added by sam back in 2002, and now seems a > >bit low. Our maximum MTU at work has always been 9120 (implying 9138 > >for ETHER_MAX_LEN_JUMBO), and we have hardware in production now that > >defaults to 12000. The ixgbe driver doesn't use this constant, bu > >the cxgbe driver does. Does anyone know a reason I should *not* > >increase it to a more reasonable level? (9216 would be my choice if > >we wanted to stick with values in the 9k range.) Per above, the various drivers should just be fixed to not use this define... P.S. So, apparently people do use jumbo frames. My question to people using them is do you limit your use of jumbo frames to broadcast domains where you can set the MTU properly on all the machine in the domain? Do you have to do special work to make sure you get the correct MTU to be compatible w/ all your hardware? i.e. find the hardware w/ the smallest supported MTU and use that? Please reply in private mail unless you feel that your response would be useful for the whole list. I have a project that I'd like to do that would allow easier and wide spread use of jumbo frames. Thanks. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-net@FreeBSD.ORG Wed Jan 8 01:31:52 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D870E60A for ; Wed, 8 Jan 2014 01:31:52 +0000 (UTC) Received: from mail.lhr1.as41113.net (mail.lhr1.as41113.net [91.208.177.22]) by mx1.freebsd.org (Postfix) with ESMTP id 9EAED15DF for ; Wed, 8 Jan 2014 01:31:52 +0000 (UTC) Received: from [172.16.10.171] (unknown [91.208.177.70]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lhr1.as41113.net (Postfix) with ESMTPS id 3dzXxL4M7lz7vbZ; Wed, 8 Jan 2014 01:31:50 +0000 (UTC) Message-ID: <52CCAA85.60107@rewt.org.uk> Date: Wed, 08 Jan 2014 01:31:49 +0000 From: Joe Holden User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Garrett Wollman , freebsd-net@freebsd.org Subject: Re: ETHER_MAX_LEN_JUMBO References: <21196.29430.733181.353677@hergotha.csail.mit.edu> <52CC9EF0.5010504@rewt.org.uk> <20140108012215.GV99167@funkthat.com> In-Reply-To: <20140108012215.GV99167@funkthat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 08 Jan 2014 01:31:52 -0000 On 08/01/2014 01:22, John-Mark Gurney wrote: > Joe Holden wrote this message on Wed, Jan 08, 2014 at 00:42 +0000: >> 16k frames are available on commidity intel cards so perhaps a bump to >> 16k should be enough for the foreseeable future, although saying that >> there is nothing to stop another big leap in frame sizes. >> >> We should probably be ahead of the curve here, rather than playing catch >> up with vendors. Would it be possible to limit the max size by looking >> at drivers in the tree at compile-time, perhaps have them declare the >> max frame size the supported hardware can handle? > > Why do we even need this define? > > atse uses it to create a buffer so it doesn't have to deal w/ data being > split between mbufs... why they didn't use m_copydata + the ofset, I > don't know, but shouldn't be hard to fix the driver.. > > cas uses it instead of reading what the interface MTU is when programming > the max length of a frame... > > ng_eiface just uses it to limit how large you can set your MTU... > > It is used to define ETHERMTU_JUMBO, which is used by a few drivers > (cas, cxgb, cxgbe and mxge) to either set the default mtu, or limit how > large the MTU can be set to... > > I would say we should just remove these defines... If a card has an > MTU limit, let it define it's own, not use some fake limit by the rest > of the system... > This sounds like a much better idea if it isn't limited by the stack architecture, if it is only a handful of drivers that even care then the obviously correct solution is to remove this define entirely. >> On 07/01/2014 21:34, Garrett Wollman wrote: >>> In , the constant ETHER_MAX_LEN_JUMBO is set to 9018. >>> According to svn, this was added by sam back in 2002, and now seems a >>> bit low. Our maximum MTU at work has always been 9120 (implying 9138 >>> for ETHER_MAX_LEN_JUMBO), and we have hardware in production now that >>> defaults to 12000. The ixgbe driver doesn't use this constant, bu >>> the cxgbe driver does. Does anyone know a reason I should *not* >>> increase it to a more reasonable level? (9216 would be my choice if >>> we wanted to stick with values in the 9k range.) > > Per above, the various drivers should just be fixed to not use this > define... > > P.S. So, apparently people do use jumbo frames. My question to people > using them is do you limit your use of jumbo frames to broadcast domains > where you can set the MTU properly on all the machine in the domain? Do > you have to do special work to make sure you get the correct MTU to be > compatible w/ all your hardware? i.e. find the hardware w/ the smallest > supported MTU and use that? > > Please reply in private mail unless you feel that your response would > be useful for the whole list. I have a project that I'd like to do that > would allow easier and wide spread use of jumbo frames. > > Thanks. > From owner-freebsd-net@FreeBSD.ORG Wed Jan 8 03:07:21 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 01060F1E for ; Wed, 8 Jan 2014 03:07:21 +0000 (UTC) Received: from mail-yh0-x22c.google.com (mail-yh0-x22c.google.com [IPv6:2607:f8b0:4002:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A85C212DC for ; Wed, 8 Jan 2014 03:07:20 +0000 (UTC) Received: by mail-yh0-f44.google.com with SMTP id f64so215602yha.31 for ; Tue, 07 Jan 2014 19:07:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=haqp6VtkfZduah72f51B1gBg7kWjAPwqlXYKdpdcGPI=; b=e8Ydgc3GQh3jYCEBuFDljaV7TKTTkGPWY1rsrRYDQUY05CQZFo74Y/sLLtC9wr3qHB rRvclxC/zH/yR+bK6IJn2vLJPpwaNlmAwx1FHyA1xiHgQpxLYcnmEuav4RLp/LusoNte q+xeb0K/7ns0CK4r/RFr2vJwRH+8/3cw9TR5g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:organization:user-agent :mime-version:to:subject:references:in-reply-to:content-type; bh=haqp6VtkfZduah72f51B1gBg7kWjAPwqlXYKdpdcGPI=; b=Ee6G2iAtNgA2WNDfip0GvnPF3jq965lEqIiLsWqG1ULgLumUpQQvEN9p78i3T7HXA8 8v/h+Ov01jKFuG38aMQEwT8Ny707np+7hxqP07zObgSBvBRhh0RUuhJ87OxVhxAAFr4v X9vOnYgzKlh2uvtY8z1uWvR8mbw80tSlkObsCdIus0z88JRe2nQgxyotE3Nl+lxnkcGX R5PpXAWemnkPuJmThlcv+7dh362YflCwo1InuLmb0RApfPyJDZDVjveYBdkahEhnCUtT GqHR3pC4+VMyWF+sfrVhti0YvU1qh8SGCUT7tir8Y0g1ZhI/57M2+BcwYnkP0kPWppmz BBwg== X-Gm-Message-State: ALoCoQndyfmORZAOudbYzi0pqBqPpDltkznQlWhR8lhJyhkvoJ49WWq9rd4wG9H8PQ87skelWQIE X-Received: by 10.236.151.41 with SMTP id a29mr84338026yhk.39.1389150439833; Tue, 07 Jan 2014 19:07:19 -0800 (PST) Received: from hackintosh.wemm.org ([2601:9:e80:770:69a1:2b30:eab6:4149]) by mx.google.com with ESMTPSA id d7sm26833177yhd.24.2014.01.07.19.07.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 07 Jan 2014 19:07:16 -0800 (PST) Message-ID: <52CCC0DF.1020007@wemm.org> Date: Tue, 07 Jan 2014 19:07:11 -0800 From: Peter Wemm Organization: World Domination in progress. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Mike Tancsa , freebsd-net@freebsd.org, eadler@freebsd.org, rrs@freebsd.org Subject: Re: TCP question: Is this simultaneous close handling broken? References: <52CB3AE9.3030107@wemm.org> <52CC5F2E.5030201@wemm.org> <52CC8246.7080609@wemm.org> <52CC903C.5090706@sentex.net> In-Reply-To: <52CC903C.5090706@sentex.net> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lnlDPe6q6u8Qe90FEFXPpNMAbTlf7Tclu" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 08 Jan 2014 03:07:21 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --lnlDPe6q6u8Qe90FEFXPpNMAbTlf7Tclu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 1/7/14, 3:39 PM, Mike Tancsa wrote: > On 1/7/2014 5:40 PM, Peter Wemm wrote: >=20 >> The packet may be dropped without processing the FIN flag. >=20 >> MFC after: never >=20 > Hi, > Are there any potential side effects to this fix ? The original > author said they were not going to MFC due to possible regressions. I > know you probably see more FreeBSD traffic then most at Y!, and so are > very sensitive to this, but thought I would ask for clarification. >=20 > ---Mike Actually, I'm very troubled by that entire chunk of code. This is the actual fix: ------------------------------------------------------------------------ r239672 | rrs | 2012-08-25 02:26:37 -0700 (Sat, 25 Aug 2012) | 12 lines This small change takes care of a race condition that can occur when both sides close at the same time. If that occurs, without this fix the connection enters FIN1 on both sides and they will forever send FIN|ACK at each other until the connection times out. This is because we stopped processing the FIN|ACK and thus did not advance the sequence and so never ACK'd each others FIN. This fix adjusts it so we *do* process the FIN properly and the race goes away ;-) MFC after: 1 month ------------------------------------------------------------------------ It was MFC'ed all the way to stable/6 in Feb 2013. r258821 from the PR does not handle the case where a fin arrives while we= are in a retransmit state ourselves due to packet loss and interferes wit= h the retransmits. r258821 needs to be backed out. I'm not convinced that r239672 is complete, or even entirely correct. For completeness I'm concerned about the by the if (tp->t_flags & TF_SACK_PERMIT) .. goto drop; scenario. Shouldn't the TH_FIN checks be moved so that it looks more like this? @@ -2534,16 +2535,6 @@ } tp->snd_nxt =3D th->th_ack; tp->snd_cwnd =3D tp->t_maxseg; - if ((thflags & TH_FIN) && - (TCPS_HAVERCVDFIN(tp->t_state) =3D=3D 0)) { - /* - * If its a fin we need to process - * it to avoid a race where both - * sides enter FIN-WAIT and send FIN|ACK - * at the same time. - */ - break; - } (void) tcp_output(tp); KASSERT(tp->snd_limited <=3D 2, ("%s: tp->snd_limited too big", @@ -2553,7 +2544,11 @@ (tp->t_dupacks - tp->snd_limited); if (SEQ_GT(onxt, tp->snd_nxt)) tp->snd_nxt =3D onxt; - goto drop; + if ((thflags & TH_FIN) && + (TCPS_HAVERCVDFIN(tp->t_state) =3D=3D 0)) + break; /* respond to incoming FIN */ + else + goto drop; } else if (V_tcp_do_rfc3042) { cc_ack_received(tp, th, CC_DUPACK); u_long oldcwnd =3D tp->snd_cwnd; ie: respond to it as we normally would, but check to see if it's a new FI= N state before discarding it? NetBSD handle this differently. They seem to check to see if it's a genuinely redundant/duplicate segment earlier and leverage it here. It seems like our handling of this is all wrong. --=20 Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6F= JV UTF-8: for when a ' just won\342\200\231t do. --lnlDPe6q6u8Qe90FEFXPpNMAbTlf7Tclu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLMwOMACgkQFRKuUnJ3cX9fbACgh2tebjkpETkbd4MAIZCjSFng wOEAn3x8QeIsEoI7W29UXd67FtC/0u3D =kzOO -----END PGP SIGNATURE----- --lnlDPe6q6u8Qe90FEFXPpNMAbTlf7Tclu-- From owner-freebsd-net@FreeBSD.ORG Wed Jan 8 03:40:14 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 80C922A6 for ; Wed, 8 Jan 2014 03:40:14 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 56E571514 for ; Wed, 8 Jan 2014 03:40:14 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s083e0v3023323 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Jan 2014 19:40:01 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s083e0CV023307; Tue, 7 Jan 2014 19:40:00 -0800 (PST) (envelope-from jmg) Date: Tue, 7 Jan 2014 19:40:00 -0800 From: John-Mark Gurney To: Joe Holden Subject: Re: ETHER_MAX_LEN_JUMBO Message-ID: <20140108033959.GX99167@funkthat.com> Mail-Followup-To: Joe Holden , Garrett Wollman , freebsd-net@freebsd.org References: <21196.29430.733181.353677@hergotha.csail.mit.edu> <52CC9EF0.5010504@rewt.org.uk> <20140108012215.GV99167@funkthat.com> <52CCAA85.60107@rewt.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52CCAA85.60107@rewt.org.uk> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Tue, 07 Jan 2014 19:40:01 -0800 (PST) Cc: freebsd-net@freebsd.org, Garrett Wollman X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 08 Jan 2014 03:40:14 -0000 Joe Holden wrote this message on Wed, Jan 08, 2014 at 01:31 +0000: > On 08/01/2014 01:22, John-Mark Gurney wrote: > >Joe Holden wrote this message on Wed, Jan 08, 2014 at 00:42 +0000: > >>16k frames are available on commidity intel cards so perhaps a bump to > >>16k should be enough for the foreseeable future, although saying that > >>there is nothing to stop another big leap in frame sizes. > >> > >>We should probably be ahead of the curve here, rather than playing catch > >>up with vendors. Would it be possible to limit the max size by looking > >>at drivers in the tree at compile-time, perhaps have them declare the > >>max frame size the supported hardware can handle? > > > >Why do we even need this define? > > > >atse uses it to create a buffer so it doesn't have to deal w/ data being > >split between mbufs... why they didn't use m_copydata + the ofset, I > >don't know, but shouldn't be hard to fix the driver.. > > > >cas uses it instead of reading what the interface MTU is when programming > >the max length of a frame... > > > >ng_eiface just uses it to limit how large you can set your MTU... > > > >It is used to define ETHERMTU_JUMBO, which is used by a few drivers > >(cas, cxgb, cxgbe and mxge) to either set the default mtu, or limit how > >large the MTU can be set to... > > > >I would say we should just remove these defines... If a card has an > >MTU limit, let it define it's own, not use some fake limit by the rest > >of the system... > > > This sounds like a much better idea if it isn't limited by the stack > architecture, if it is only a handful of drivers that even care then the > obviously correct solution is to remove this define entirely. I used fxr.watson.org to do this research: http://fxr.watson.org/fxr/ident?i=ETHER_MAX_LEN_JUMBO Just so you can browse around for yourself. :) Hmm.. to make matters more interesting, the kernel version of cxgb does not default to jumbo frames, BUT, the module version of cxgb does default.. It's probably because no one uses the module that no one noticed the difference... If you need help generating patches, let me know.. I can commit them once they are tested, but I don't have hardware to test myself... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-net@FreeBSD.ORG Wed Jan 8 19:18:43 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 02300B8D for ; Wed, 8 Jan 2014 19:18:43 +0000 (UTC) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AF493183A for ; Wed, 8 Jan 2014 19:18:42 +0000 (UTC) Received: by mail-pa0-f51.google.com with SMTP id fa1so2264678pad.10 for ; Wed, 08 Jan 2014 11:18:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=wO7PlkoKP7FqMbG3VSl1TjwqEfVwiFZt9BU82Bx+JcE=; b=1SCkax6QAj9fz9DEVf+m3u/cY972NZu2T3su6/rSX9QxCY57HlT+6yWSkbqvu0iVgd NxErsNqGRr9KdWOXbRi9fwQ6jD6B3FRxrHZGOx420CLsyXY6aEj+MtJiJtwvwfjGJ85a WmtSvdmOfnsRvymGjpf8Qwn0Dp+9PretWqDOQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=wO7PlkoKP7FqMbG3VSl1TjwqEfVwiFZt9BU82Bx+JcE=; b=aXAayf+0ZEtrkMuIMWcIheb//ffk4t5ZIDbwmkfKEzTVyobaNrCXgZv8NARRsO/AbF qzfiYOvjYwmxqwrb5msCmH9tyKWHi/gAEU8xqj+Vdtv+Nih+WySIuKBKAPNJ52OSdNg8 /QY50Ty/yxRGA1vh+Pg1CjSVQK5mN2AdFcCAC5K7L+I6/2MHvNZ7H5vnv0BTxay5jOJM NNWMivsyO9OyPbU0Lp9x7rjpFg19zH0YxfrL1lmB5oSgaxlqxAbKxCZ5qN5hzqP+WLrF 3uD2DhoV6eMWnId8eqRRDcH+itittxlaiLSSjRy/+tnl43ckb6m3L07psgkMIDpKT2sn ra5Q== X-Gm-Message-State: ALoCoQkRJ3Aqfu57nu+VLTfV4e5x1EJ3ZffzsgobbQyCYluEedr83bxMAOgi5qRNxy3vNk+BTRQC X-Received: by 10.66.232.40 with SMTP id tl8mr15134556pac.137.1389208722104; Wed, 08 Jan 2014 11:18:42 -0800 (PST) Received: from hater-dm.corp.yahoo.com (nat-dip4.cfw-a-gci.corp.yahoo.com. [209.131.62.113]) by mx.google.com with ESMTPSA id sg1sm4374635pbb.16.2014.01.08.11.18.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 08 Jan 2014 11:18:41 -0800 (PST) Message-ID: <52CDA490.5060002@wemm.org> Date: Wed, 08 Jan 2014 11:18:40 -0800 From: Peter Wemm User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Mike Tancsa , freebsd-net@freebsd.org, eadler@freebsd.org, rrs@freebsd.org Subject: Re: TCP question: Is this simultaneous close handling broken? References: <52CB3AE9.3030107@wemm.org> <52CC5F2E.5030201@wemm.org> <52CC8246.7080609@wemm.org> <52CC903C.5090706@sentex.net> <52CCC0DF.1020007@wemm.org> In-Reply-To: <52CCC0DF.1020007@wemm.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 08 Jan 2014 19:18:43 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 1/7/14, 7:07 PM, Peter Wemm wrote: > On 1/7/14, 3:39 PM, Mike Tancsa wrote: >> On 1/7/2014 5:40 PM, Peter Wemm wrote: >> >>> The packet may be dropped without processing the FIN flag. >> >>> MFC after: never >> >> Hi, Are there any potential side effects to this fix ? The original >> author said they were not going to MFC due to possible regressions. >> I know you probably see more FreeBSD traffic then most at Y!, and so >> are very sensitive to this, but thought I would ask for >> clarification. >> >> ---Mike > > Actually, I'm very troubled by that entire chunk of code. I think the correct fix is to back out r239672 from rrs, and modify r258821 from the PR so that it understands that that it applies to only the first FIN packet we get. I slightly moved the test for clarity and for room to comment. http://people.freebsd.org/~peter/tcp_input.c.diff I believe that eadler's r258821 interferes with normal cc operation for a small window after the remote has sent a FIN. Rev r258821 also turns r239672 into dead code. - -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV UTF-8: for when a ' just won\342\200\231t do. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLNpI4ACgkQFRKuUnJ3cX9yHwCfUVVXcsfHtKRfsCeQ1OVksAYW FskAn3PuJozJw0kVKpfJuaEoHBOClTdY =63Li -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Thu Jan 9 01:55:50 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 31408882 for ; Thu, 9 Jan 2014 01:55:50 +0000 (UTC) Received: from mail-qe0-x243.google.com (mail-qe0-x243.google.com [IPv6:2607:f8b0:400d:c02::243]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DB7C91863 for ; Thu, 9 Jan 2014 01:55:49 +0000 (UTC) Received: by mail-qe0-f67.google.com with SMTP id b10so726608qen.2 for ; Wed, 08 Jan 2014 17:55:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=QWZGWx5N3oakoVApICFhwpYcxJP9jGTs23bgY8gPhXw=; b=DHUmjiCWljKnIdaiRTRHcjnMYqNls1rqW4Vh5cz8ga0RmStRnyUuEM2fvHc/Zcs/D0 BLpl/L1c6GJH4e5q5wdiBt1+qk66n1tZ8IhAujc3Z1AwA9U+nsady6yXRTg7b1MOX1v+ MWYADwdLdbRI+Ds9bbiulqcbwyUwp7dzs5gk96FfEpUWqpM6Wbr8W3l6P1CHZmKq1Uek XlxctvQdfTjOLAoY50R//8xFK431T1qL6CeepOIQ8VQwS+LXEjbE5OlRE+cGCweGY148 KRFbSiqhR5hgTb2VMxRek4ZJejnhbBv0o2H1GMcoPCmTUMIJMb18QsYTWDFvcrf3Z1HV qj2g== MIME-Version: 1.0 X-Received: by 10.229.65.130 with SMTP id j2mr1297402qci.6.1389232549046; Wed, 08 Jan 2014 17:55:49 -0800 (PST) Received: by 10.96.97.33 with HTTP; Wed, 8 Jan 2014 17:55:48 -0800 (PST) Date: Wed, 8 Jan 2014 20:55:48 -0500 Message-ID: Subject: Re : NDP prefix list locking From: Ritesh Shah To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 09 Jan 2014 01:55:50 -0000 Hi Mark, I have run into the same problem. Is your proposed solution being actively pursued? I have a question about your proposed solution. You have added locks around the list manipulation routines/code blocks. However I see that individual elements of the two lists can be accessed outside of the rw locks you added. For instance in in6_control(), prelist_update() and nd6_free(). Is it possible to have use-after-free situation in these routines if the element gets deleted by a different thread at the same time? Should the elements be reference counted so that it is safe to access them outside of the rw locks. Thanks, Ritesh On Mon, Feb 18, 2013 at 7:05 PM, Mark Johnston > wrote: >* Hi Everyone, *>>* For the past little while I've been tracking down some memory corruption *>* issues that seem to be caused by a double free that can happen when *>* destroying an IPv6-enabled interface or when removing an IPv6 address *>* from an interface. *>>* The problem seems to be caused by a lack of locking for nd_prefix, the *>* global IPv6 prefix list. There's a callout that periodically executes *>* nd6_timer(), which purges expired prefixes (among other things). There's *>* nothing preventing an expired prefix from being freed twice if a user *>* happens to destroy the corresponding address or IP address at the same *>* time. In fact, a prefix with an infinite lifetime can be double freed as *>* well, since the first thing prelist_remove() does is set the input *>* prefix's vltime field to 0. *>>* I'd like to fix this, and the patch below is my attempt at adding some *>* locking to accesses of the prefix and default router lists. It's only *>* received very light testing so far, but I was hoping that others could *>* either review/test the patch, or suggest alternative approaches to *>* fixing this. My approach here has been to add two rw locks - one for *>* the prefix list and one for the default router list. I'm not very *>* familiar with the NDP code so I'm very much open to comments and *>* suggestions. :) *>>* Thanks, *>* -Mark *>>* diff --git a/sys/netinet6/in6.c b/sys/netinet6/in6.c *>* index e260e5d..3cb327c 100644 *>* --- a/sys/netinet6/in6.c *>* +++ b/sys/netinet6/in6.c *>* @@ -805,8 +805,11 @@ in6_control(struct socket *so, u_long cmd, caddr_t data, *>* */ *>* pr = ia->ia6_ndpr; *>* in6_purgeaddr(&ia->ia_ifa); *>* - if (pr && pr->ndpr_refcnt == 0) *>* + if (pr && pr->ndpr_refcnt == 0) { *>* + ND_PREFIX_WLOCK(); *>* prelist_remove(pr); *>* + ND_PREFIX_WUNLOCK(); *>* + } *>* EVENTHANDLER_INVOKE(ifaddr_event, ifp); *>* break; *>* } *>* diff --git a/sys/netinet6/nd6.c b/sys/netinet6/nd6.c *>* index fd420d8..d96340c 100644 *>* --- a/sys/netinet6/nd6.c *>* +++ b/sys/netinet6/nd6.c *>* @@ -117,6 +117,9 @@ static int nd6_inuse, nd6_allocated; *>* VNET_DEFINE(struct nd_drhead, nd_defrouter); *>* VNET_DEFINE(struct nd_prhead, nd_prefix); *>>* +struct rwlock nd_prefix_rwlock; *>* +struct rwlock nd_defrouter_rwlock; *>* + *>* VNET_DEFINE(int, nd6_recalc_reachtm_interval) = ND6_RECALC_REACHTM_INTERVAL; *>* #define V_nd6_recalc_reachtm_interval VNET(nd6_recalc_reachtm_interval) *>>* @@ -143,6 +146,7 @@ nd6_init(void) *>* { *>* int i; *>>* + rw_init(&nd_prefix_rwlock, "nd_prefix rwlock"); *>* LIST_INIT(&V_nd_prefix); *>>* all1_sa.sin6_family = AF_INET6; *>* @@ -151,6 +155,7 @@ nd6_init(void) *>* all1_sa.sin6_addr.s6_addr[i] = 0xff; *>>* /* initialization of the default router list */ *>* + rw_init(&nd_defrouter_rwlock, "nd_defrouter rwlock"); *>* TAILQ_INIT(&V_nd_defrouter); *>>* /* start timer */ *>* @@ -586,10 +591,14 @@ nd6_timer(void *arg) *>* nd6_timer, curvnet); *>>* /* expire default router list */ *>* + ND_PREFIX_RLOCK(); *>* + ND_DEFRTR_WLOCK(); *>* TAILQ_FOREACH_SAFE(dr, &V_nd_defrouter, dr_entry, ndr) { *>* if (dr->expire && dr->expire < time_second) *>* defrtrlist_del(dr); *>* } *>* + ND_DEFRTR_WUNLOCK(); *>* + ND_PREFIX_RUNLOCK(); *>>* /* *>* * expire interface addresses. *>* @@ -664,6 +673,7 @@ nd6_timer(void *arg) *>* } *>>* /* expire prefix list */ *>* + ND_PREFIX_WLOCK(); *>* LIST_FOREACH_SAFE(pr, &V_nd_prefix, ndpr_entry, npr) { *>* /* *>* * check prefix lifetime. *>* @@ -680,6 +690,7 @@ nd6_timer(void *arg) *>* prelist_remove(pr); *>* } *>* } *>* + ND_PREFIX_WUNLOCK(); *>* CURVNET_RESTORE(); *>* } *>>* @@ -770,6 +781,8 @@ nd6_purge(struct ifnet *ifp) *>* * in the routing table, in order to keep additional side effects as *>* * small as possible. *>* */ *>* + ND_PREFIX_RLOCK(); *>* + ND_DEFRTR_WLOCK(); *>* TAILQ_FOREACH_SAFE(dr, &V_nd_defrouter, dr_entry, ndr) { *>* if (dr->installed) *>* continue; *>* @@ -785,8 +798,11 @@ nd6_purge(struct ifnet *ifp) *>* if (dr->ifp == ifp) *>* defrtrlist_del(dr); *>* } *>* + ND_DEFRTR_WUNLOCK(); *>* + ND_PREFIX_RUNLOCK(); *>>* /* Nuke prefix list entries toward ifp */ *>* + ND_PREFIX_WLOCK(); *>* LIST_FOREACH_SAFE(pr, &V_nd_prefix, ndpr_entry, npr) { *>* if (pr->ndpr_ifp == ifp) { *>* /* *>* @@ -808,6 +824,7 @@ nd6_purge(struct ifnet *ifp) *>* prelist_remove(pr); *>* } *>* } *>* + ND_PREFIX_WUNLOCK(); *>>* /* cancel default outgoing interface setting */ *>* if (V_nd6_defifindex == ifp->if_index) *>* @@ -898,6 +915,7 @@ nd6_is_new_addr_neighbor(struct sockaddr_in6 *addr, struct ifnet *ifp) *>* * If the address matches one of our on-link prefixes, it should be a *>* * neighbor. *>* */ *>* + ND_PREFIX_RLOCK(); *>* LIST_FOREACH(pr, &V_nd_prefix, ndpr_entry) { *>* if (pr->ndpr_ifp != ifp) *>* continue; *>* @@ -929,9 +947,12 @@ nd6_is_new_addr_neighbor(struct sockaddr_in6 *addr, struct ifnet *ifp) *>* } *>>* if (IN6_ARE_MASKED_ADDR_EQUAL(&pr->ndpr_prefix.sin6_addr, *>* - &addr->sin6_addr, &pr->ndpr_mask)) *>* + &addr->sin6_addr, &pr->ndpr_mask)) { *>* + ND_PREFIX_RUNLOCK(); *>* return (1); *>* + } *>* } *>* + ND_PREFIX_RUNLOCK(); *>>* /* *>* * If the address is assigned on the node of the other side of *>* @@ -1229,6 +1250,7 @@ nd6_ioctl(u_long cmd, caddr_t data, struct ifnet *ifp) *>* * obsolete API, use sysctl under net.inet6.icmp6 *>* */ *>* bzero(drl, sizeof(*drl)); *>* + ND_DEFRTR_RLOCK(); *>* TAILQ_FOREACH(dr, &V_nd_defrouter, dr_entry) { *>* if (i >= DRLSTSIZ) *>* break; *>* @@ -1241,6 +1263,7 @@ nd6_ioctl(u_long cmd, caddr_t data, struct ifnet *ifp) *>* drl->defrouter[i].if_index = dr->ifp->if_index; *>* i++; *>* } *>* + ND_DEFRTR_RUNLOCK(); *>* break; *>* case SIOCGPRLST_IN6: *>* /* *>* @@ -1256,6 +1279,7 @@ nd6_ioctl(u_long cmd, caddr_t data, struct ifnet *ifp) *>* * how about separating ioctls into two? *>* */ *>* bzero(oprl, sizeof(*oprl)); *>* + ND_PREFIX_RLOCK(); *>* LIST_FOREACH(pr, &V_nd_prefix, ndpr_entry) { *>* struct nd_pfxrouter *pfr; *>* int j; *>* @@ -1301,6 +1325,7 @@ nd6_ioctl(u_long cmd, caddr_t data, struct ifnet *ifp) *>>* i++; *>* } *>* + ND_PREFIX_RUNLOCK(); *>>* break; *>* case OSIOCGIFINFO_IN6: *>* @@ -1449,6 +1474,7 @@ nd6_ioctl(u_long cmd, caddr_t data, struct ifnet *ifp) *>* /* flush all the prefix advertised by routers */ *>* struct nd_prefix *pr, *next; *>>* + ND_PREFIX_WLOCK(); *>* LIST_FOREACH_SAFE(pr, &V_nd_prefix, ndpr_entry, next) { *>* struct in6_ifaddr *ia, *ia_next; *>>* @@ -1467,6 +1493,7 @@ nd6_ioctl(u_long cmd, caddr_t data, struct ifnet *ifp) *>* } *>* prelist_remove(pr); *>* } *>* + ND_PREFIX_WUNLOCK(); *>* break; *>* } *>* case SIOCSRTRFLUSH_IN6: *>* @@ -1475,9 +1502,13 @@ nd6_ioctl(u_long cmd, caddr_t data, struct ifnet *ifp) *>* struct nd_defrouter *dr, *next; *>>* defrouter_reset(); *>* + ND_PERFIX_RLOCK(); *>* + ND_DEFRTR_WLOCK(); *>* TAILQ_FOREACH_SAFE(dr, &V_nd_defrouter, dr_entry, next) { *>* defrtrlist_del(dr); *>* } *>* + ND_DEFRTR_WUNLOCK(); *>* + ND_PREFIX_RUNLOCK(); *>* defrouter_select(); *>* break; *>* } *>* @@ -2268,23 +2299,30 @@ nd6_sysctl_drlist(SYSCTL_HANDLER_ARGS) *>* d.rtaddr.sin6_family = AF_INET6; *>* d.rtaddr.sin6_len = sizeof(d.rtaddr); *>>* + error = sysctl_wire_old_buffer(req, 0); *>* + if (error != 0) *>* + return (error); *>* + *>* /* *>* * XXX locking *>* */ *>* + ND_DEFRTR_RLOCK(); *>* TAILQ_FOREACH(dr, &V_nd_defrouter, dr_entry) { *>* d.rtaddr.sin6_addr = dr->rtaddr; *>* error = sa6_recoverscope(&d.rtaddr); *>* if (error != 0) *>* - return (error); *>* + break; *>* d.flags = dr->flags; *>* d.rtlifetime = dr->rtlifetime; *>* d.expire = dr->expire; *>* d.if_index = dr->ifp->if_index; *>* error = SYSCTL_OUT(req, &d, sizeof(d)); *>* if (error != 0) *>* - return (error); *>* + break; *>* } *>* - return (0); *>* + ND_DEFRTR_RUNLOCK(); *>* + *>* + return (error); *>* } *>>* static int *>* @@ -2307,9 +2345,14 @@ nd6_sysctl_prlist(SYSCTL_HANDLER_ARGS) *>* s6.sin6_family = AF_INET6; *>* s6.sin6_len = sizeof(s6); *>>* + error = sysctl_wire_old_buffer(req, 0); *>* + if (error != 0) *>* + return (error); *>* + *>* /* *>* * XXX locking *>* */ *>* + ND_PREFIX_RLOCK(); *>* LIST_FOREACH(pr, &V_nd_prefix, ndpr_entry) { *>* p.prefix = pr->ndpr_prefix; *>* if (sa6_recoverscope(&p.prefix)) { *>* @@ -2341,7 +2384,7 @@ nd6_sysctl_prlist(SYSCTL_HANDLER_ARGS) *>* p.advrtrs++; *>* error = SYSCTL_OUT(req, &p, sizeof(p)); *>* if (error != 0) *>* - return (error); *>* + break; *>* LIST_FOREACH(pfr, &pr->ndpr_advrtrs, pfr_entry) { *>* s6.sin6_addr = pfr->router->rtaddr; *>* if (sa6_recoverscope(&s6)) *>* @@ -2349,9 +2392,13 @@ nd6_sysctl_prlist(SYSCTL_HANDLER_ARGS) *>* "scope error in prefix list (%s)\n", *>* ip6_sprintf(ip6buf, &pfr->router->rtaddr)); *>* error = SYSCTL_OUT(req, &s6, sizeof(s6)); *>* - if (error != 0) *>* + if (error != 0) { *>* + ND_PREFIX_RUNLOCK(); *>* return (error); *>* + } *>* } *>* } *>* - return (0); *>* + ND_PREFIX_RUNLOCK(); *>* + *>* + return (error); *>* } *>* diff --git a/sys/netinet6/nd6.h b/sys/netinet6/nd6.h *>* index 94202e1..bc5ff2d 100644 *>* --- a/sys/netinet6/nd6.h *>* +++ b/sys/netinet6/nd6.h *>* @@ -38,6 +38,7 @@ *>* #define RTF_ANNOUNCE RTF_PROTO2 *>* #endif *>>* +#include *>* #include *>* #include *>>* @@ -341,6 +342,35 @@ VNET_DECLARE(int, nd6_onlink_ns_rfc4861); *>* #define V_nd6_debug VNET(nd6_debug) *>* #define V_nd6_onlink_ns_rfc4861 VNET(nd6_onlink_ns_rfc4861) *>>* +/* Lock to protect access to the nd_prefix list. */ *>* +extern struct rwlock nd_prefix_rwlock; *>* +#define ND_PREFIX_RLOCK() rw_rlock(&nd_prefix_rwlock) *>* +#define ND_PREFIX_RUNLOCK() rw_runlock(&nd_prefix_rwlock) *>* +#define ND_PREFIX_WLOCK() rw_wlock(&nd_prefix_rwlock) *>* +#define ND_PREFIX_WUNLOCK() rw_wunlock(&nd_prefix_rwlock) *>* +#define ND_PREFIX_LOCK_ASSERT() rw_assert(&nd_prefix_rwlock, RA_LOCKED) *>* +#define ND_PREFIX_RLOCK_ASSERT() rw_assert(&nd_prefix_rwlock, RA_RLOCKED) *>* +#define ND_PREFIX_WLOCK_ASSERT() rw_assert(&nd_prefix_rwlock, RA_WLOCKED) *>* +#define ND_PREFIX_WLOCK_OWNED() rw_wowned(&nd_prefix_rwlock) *>* + *>* +/* *>* + * Lock to protect access to the nd_defrouter list. A shared lock should be *>* + * acquired on the prefix list before acquiring an exclusive lock on the router *>* + * list and calling defrouterlist_del() in order to avoid lock order reversals. *>* + */ *>* +extern struct rwlock nd_defrouter_rwlock; *>* +#define ND_DEFRTR_RLOCK() rw_rlock(&nd_defrouter_rwlock) *>* +#define ND_DEFRTR_RUNLOCK() rw_runlock(&nd_defrouter_rwlock) *>* +#define ND_DEFRTR_WLOCK() rw_wlock(&nd_defrouter_rwlock) *>* +#define ND_DEFRTR_WUNLOCK() rw_wunlock(&nd_defrouter_rwlock) *>* +#define ND_DEFRTR_LOCK_ASSERT() rw_assert(&nd_defrouter_rwlock, \ *>* + RA_LOCKED) *>* +#define ND_DEFRTR_RLOCK_ASSERT() rw_assert(&nd_defrouter_rwlock, \ *>* + RA_RLOCKED) *>* +#define ND_DEFRTR_WLOCK_ASSERT() rw_assert(&nd_defrouter_rwlock, \ *>* + RA_WLOCKED) *>* +#define ND_DEFRTR_WLOCK_OWNED() rw_wowned(&nd_defrouter_rwlock) *>* + *>* #define nd6log(x) do { if (V_nd6_debug) log x; } while (/*CONSTCOND*/ 0) *>>* VNET_DECLARE(struct callout, nd6_timer_ch); *>* diff --git a/sys/netinet6/nd6_rtr.c b/sys/netinet6/nd6_rtr.c *>* index f6bae0c..e5c63b9 100644 *>* --- a/sys/netinet6/nd6_rtr.c *>* +++ b/sys/netinet6/nd6_rtr.c *>* @@ -499,14 +499,16 @@ defrouter_addreq(struct nd_defrouter *new) *>* struct nd_defrouter * *>* defrouter_lookup(struct in6_addr *addr, struct ifnet *ifp) *>* { *>* - struct nd_defrouter *dr; *>* + struct nd_defrouter *dr = NULL; *>>* + ND_DEFRTR_RLOCK(); *>* TAILQ_FOREACH(dr, &V_nd_defrouter, dr_entry) { *>* if (dr->ifp == ifp && IN6_ARE_ADDR_EQUAL(addr, &dr->rtaddr)) *>* - return (dr); *>* + break; *>* } *>* + ND_DEFRTR_RUNLOCK(); *>>* - return (NULL); /* search failed */ *>* + return (dr); /* search failed */ *>* } *>>* /* *>* @@ -548,8 +550,10 @@ defrouter_reset(void) *>* { *>* struct nd_defrouter *dr; *>>* + ND_DEFRTR_RLOCK(); *>* TAILQ_FOREACH(dr, &V_nd_defrouter, dr_entry) *>* defrouter_delreq(dr); *>* + ND_DEFRTR_RUNLOCK(); *>>* /* *>* * XXX should we also nuke any default routers in the kernel, by *>* @@ -574,11 +578,13 @@ defrtrlist_del(struct nd_defrouter *dr) *>* deldr = dr; *>* defrouter_delreq(dr); *>* } *>* + ND_DEFRTR_WLOCK_ASSERT(); *>* TAILQ_REMOVE(&V_nd_defrouter, dr, dr_entry); *>>* /* *>* * Also delete all the pointers to the router in each prefix lists. *>* */ *>* + ND_PREFIX_RLOCK_ASSERT(); *>* LIST_FOREACH(pr, &V_nd_prefix, ndpr_entry) { *>* struct nd_pfxrouter *pfxrtr; *>* if ((pfxrtr = pfxrtr_lookup(pr, dr)) != NULL) *>* @@ -636,6 +642,7 @@ defrouter_select(void) *>* * We just pick up the first reachable one (if any), assuming that *>* * the ordering rule of the list described in defrtrlist_update(). *>* */ *>* + ND_DEFRTR_RLOCK(); *>* TAILQ_FOREACH(dr, &V_nd_defrouter, dr_entry) { *>* IF_AFDATA_RLOCK(dr->ifp); *>* if (selected_dr == NULL && *>* @@ -657,6 +664,8 @@ defrouter_select(void) *>* " is installed\n"); *>* } *>* } *>* + ND_DEFRTR_RUNLOCK(); *>* + *>* /* *>* * If none of the default routers was found to be reachable, *>* * round-robin the list regardless of preference. *>* @@ -758,7 +767,9 @@ defrtrlist_update(struct nd_defrouter *new) *>* * defrouter_select() below will handle routing *>* * changes later. *>* */ *>* + ND_DEFRTR_WLOCK(); *>* TAILQ_REMOVE(&V_nd_defrouter, dr, dr_entry); *>* + ND_DEFRTR_WUNLOCK(); *>* n = dr; *>* goto insert; *>* } *>* @@ -784,6 +795,7 @@ insert: *>* */ *>>* /* insert at the end of the group */ *>* + ND_DEFRTR_WLOCK(); *>* TAILQ_FOREACH(dr, &V_nd_defrouter, dr_entry) { *>* if (rtpref(n) > rtpref(dr)) *>* break; *>* @@ -792,6 +804,7 @@ insert: *>* TAILQ_INSERT_BEFORE(dr, n, dr_entry); *>* else *>* TAILQ_INSERT_TAIL(&V_nd_defrouter, n, dr_entry); *>* + ND_DEFRTR_WUNLOCK(); *>>* defrouter_select(); *>>* @@ -839,6 +852,7 @@ nd6_prefix_lookup(struct nd_prefixctl *key) *>* { *>* struct nd_prefix *search; *>>* + ND_PREFIX_RLOCK(); *>* LIST_FOREACH(search, &V_nd_prefix, ndpr_entry) { *>* if (key->ndpr_ifp == search->ndpr_ifp && *>* key->ndpr_plen == search->ndpr_plen && *>* @@ -847,6 +861,7 @@ nd6_prefix_lookup(struct nd_prefixctl *key) *>* break; *>* } *>* } *>* + ND_PREFIX_RUNLOCK(); *>>* return (search); *>* } *>* @@ -887,7 +902,9 @@ nd6_prelist_add(struct nd_prefixctl *pr, struct nd_defrouter *dr, *>* new->ndpr_mask.s6_addr32[i]; *>>* /* link ndpr_entry to nd_prefix list */ *>* + ND_PREFIX_WLOCK(); *>* LIST_INSERT_HEAD(&V_nd_prefix, new, ndpr_entry); *>* + ND_PREFIX_WUNLOCK(); *>>* /* ND_OPT_PI_FLAG_ONLINK processing */ *>* if (new->ndpr_raf_onlink) { *>* @@ -938,6 +955,7 @@ prelist_remove(struct nd_prefix *pr) *>* return; /* notice here? */ *>>* /* unlink ndpr_entry from nd_prefix list */ *>* + ND_PREFIX_WLOCK_ASSERT(); *>* LIST_REMOVE(pr, ndpr_entry); *>>* /* free list of routers that adversed the prefix */ *>* @@ -1339,6 +1357,8 @@ pfxlist_onlink_check() *>* * Check if there is a prefix that has a reachable advertising *>* * router. *>* */ *>* + if (!ND_PREFIX_WLOCK_OWNED()) *>* + ND_PREFIX_RLOCK(); *>* LIST_FOREACH(pr, &V_nd_prefix, ndpr_entry) { *>* if (pr->ndpr_raf_onlink && find_pfxlist_reachable_router(pr)) *>* break; *>* @@ -1349,6 +1369,7 @@ pfxlist_onlink_check() *>* * that does not advertise any prefixes. *>* */ *>* if (pr == NULL) { *>* + ND_DEFRTR_RLOCK(); *>* TAILQ_FOREACH(dr, &V_nd_defrouter, dr_entry) { *>* struct nd_prefix *pr0; *>>* @@ -1359,6 +1380,7 @@ pfxlist_onlink_check() *>* if (pfxrtr != NULL) *>* break; *>* } *>* + ND_DEFRTR_RUNLOCK(); *>* } *>* if (pr != NULL || (!TAILQ_EMPTY(&V_nd_defrouter) && pfxrtr == NULL)) { *>* /* *>* @@ -1454,6 +1476,8 @@ pfxlist_onlink_check() *>* } *>* } *>* } *>* + if (!ND_PREFIX_WLOCK_OWNED()) *>* + ND_PREFIX_RUNLOCK(); *>>* /* *>* * Changes on the prefix status might affect address status as well. *>* @@ -1618,6 +1642,7 @@ nd6_prefix_onlink(struct nd_prefix *pr) *>* * Although such a configuration is expected to be rare, we explicitly *>* * allow it. *>* */ *>* + ND_PREFIX_RLOCK(); *>* LIST_FOREACH(opr, &V_nd_prefix, ndpr_entry) { *>* if (opr == pr) *>* continue; *>* @@ -1627,9 +1652,12 @@ nd6_prefix_onlink(struct nd_prefix *pr) *>>* if (opr->ndpr_plen == pr->ndpr_plen && *>* in6_are_prefix_equal(&pr->ndpr_prefix.sin6_addr, *>* - &opr->ndpr_prefix.sin6_addr, pr->ndpr_plen)) *>* + &opr->ndpr_prefix.sin6_addr, pr->ndpr_plen)) { *>* + ND_PREFIX_RUNLOCK(); *>* return (0); *>* + } *>* } *>* + ND_PREFIX_RUNLOCK(); *>>* /* *>* * We prefer link-local addresses as the associated interface address. *>* @@ -1730,6 +1758,7 @@ nd6_prefix_offlink(struct nd_prefix *pr) *>* * If there's one, try to make the prefix on-link on the *>* * interface. *>* */ *>* + ND_PREFIX_LOCK_ASSERT(); *>* LIST_FOREACH(opr, &V_nd_prefix, ndpr_entry) { *>* if (opr == pr) *>* continue;* From owner-freebsd-net@FreeBSD.ORG Thu Jan 9 09:07:58 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AF916B26 for ; Thu, 9 Jan 2014 09:07:58 +0000 (UTC) Received: from mail.ipfw.ru (mail.ipfw.ru [IPv6:2a01:4f8:120:6141::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7054B1DB4 for ; Thu, 9 Jan 2014 09:07:58 +0000 (UTC) Received: from [2a02:6b8:0:401:222:4dff:fe50:cd2f] (helo=ptichko.yndx.net) by mail.ipfw.ru with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1W17lG-000CnK-9P; Thu, 09 Jan 2014 09:02:30 +0400 Message-ID: <52CE6636.5080503@FreeBSD.org> Date: Thu, 09 Jan 2014 13:04:54 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Sami Halabi , Nikolay Denev Subject: Re: Interface routes left over undeletable with RADIX_MPATH References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 09 Jan 2014 09:07:58 -0000 On 03.01.2014 12:37, Sami Halabi wrote: > Hi, > I've seen this problem also... > My workaround : > ifconfig lo0 delete (or destroy and rebuild i cant remmember) > That deletef all thr ips in lo0 Hello. This should be fixed in r260379. However, fix is partial: 1) Interface aliases with the same netmask generates 2 interface routes and delete does not work properly 2) IPv6 code still does not work properly I'm working on this. > > Sami > בת×ריך 2 בינו 2014 12:29, "Nikolay Denev" כתב: > >> Hi, >> >> While digging around for the "rtfree 2" panics with RADIX_MPATH I've >> reported in misc/185092, (yeah, should've been kern, or net, not misc) >> I've noticed that the interface routes that are installed on the >> loopback interface are left over when the address is removed and >> RADIX_MPATH is used. Moreover, since these now I believe are flagged >> as RTF_PINNED it's unable to delete them. >> >> Here is what happens with 10.0-RC3 GENERIC: >> >> # ifconfig em0 10.10.10.10/24 >> # netstat -rnfinet | grep 10.10.10.10 >> # 10.10.10.10 link#1 UHS 0 0 lo0 >> # ifconfig em0 delete >> # netstat -rnfinet | grep 10.10.10.10 >> # >> >> However, this happens with RADIX_MPATH kernel: >> >> # ifconfig em0 10.10.10.10/24 >> # netstat -rnfinet | grep 10.10.10.10 >> # 10.10.10.10 link#1 UHS 0 0 lo0 >> # ifconfig em0 delete >> # netstat -rnfinet | grep 10.10.10.10 >> # 10.10.10.10 link#1 UHS 0 0 lo0 >> # route delete 10.10.10.10 -iface lo0 >> # route: writing to routing socket: No such process >> # delete host 10.10.10.10: gateway lo0 fib0: not in table >> >> The address is successfully removed from the em0 interface, but the >> route over the loopback interface stays, even survives "route flush" >> >> >> --Nikolay >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Thu Jan 9 10:42:26 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0596520A; Thu, 9 Jan 2014 10:42:26 +0000 (UTC) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6544215F1; Thu, 9 Jan 2014 10:42:24 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.7/8.14.7) with ESMTP id s09AgNBO092081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 9 Jan 2014 14:42:23 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.7/8.14.7/Submit) id s09AgNl8092080; Thu, 9 Jan 2014 14:42:23 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 9 Jan 2014 14:42:23 +0400 From: Gleb Smirnoff To: Guy Yur Subject: Re: 10.0-RC1, armv6: "pfctl -s state" crashes on BeagleBone Black due to unaligned access Message-ID: <20140109104223.GS71033@FreeBSD.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.22 (2013-10-16) Cc: freebsd-net@freebsd.org, freebsd-arm@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 09 Jan 2014 10:42:26 -0000 Guy, On Sat, Jan 04, 2014 at 03:06:02PM +0200, Guy Yur wrote: G> I am running 10.0-RC1 arm.armv6 on the BeagleBone Black. G> The "pfctl -s state" command is crashing when trying to print the G> second entry. G> G> struct pfsync_state has a size that is not divisiable by 4 or 8 leading to the G> second entry in the returned state array not being aligned and pfctl G> core dumps on Bus error when trying to access a uint32_t field. G> G> (gdb) bt G> #0 print_host (addr=0x2085a11a, port=7660, af=2 '\002', opts=1024) at G> /usr/src/sbin/pfctl/pf_print_state.c:178 G> #1 0x00021c4c in print_state (s=0x2085a0f2, opts=1024) at G> /usr/src/sbin/pfctl/pf_print_state.c:236 G> #2 0x0000c664 in pfctl_show_states (dev=, G> iface=0x0, opts=1024) at /usr/src/sbin/pfctl/pfctl.c:1095 G> G> sizeof(struct pfsync_state_key) is 36 G> sizeof(struct pfsync_state_peer) is 32 G> sizeof(struct pf_addr) is 16 G> sizeof(struct pfsync_state) is 242 G> G> Removing the __spare[2] field will allow the struct to be aligned on 8 bytes G> for the u_int64_t id field and also cover the uint32_t fields alignment G> but this will break KBI. G> G> I am currently using an inefficient workaround in pfctl_show_states G> that memcpy each entry to a struct pfsync_state on the stack G> ensuring each call to print_state receives an aligned struct. G> G> 10.0-RC1 World and kernel were compiled in a VirtualBox VM running G> 9.2-RELEASE-p2 i386. G> clang and ARM_EABI used as the default make options. For pf we are ready to break KBI. It uses same structs for internal kernel representation and for ioctl() API and this is actually a bug. Until it is properly fixed, we are doomed to break KBI always. Unfortunately, pfsync_state is not only a KBI but also a wire protocol for pfsync(4). We can't break this, since that would make different FreeBSD versions not exchanging states properly. Well, <= 8.x already is incompatible with >= 9.x, thanks yet another OpenBSD import. But we don't want to introduce another one. I will try to fix this making new structure for the ioctl. That will mean moving slowly towards divorcing internal structures and ioctl ones. I'd appreciate if you file a PR on that, so that problem won't leave forgotten in the mailing list. You can even code the bugfix :) Thanks! -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Thu Jan 9 11:43:18 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 99CFEC26; Thu, 9 Jan 2014 11:43:18 +0000 (UTC) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 21F461B0C; Thu, 9 Jan 2014 11:43:17 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.7/8.14.7) with ESMTP id s09BhA8C092833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 9 Jan 2014 15:43:10 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.7/8.14.7/Submit) id s09BhAKS092832; Thu, 9 Jan 2014 15:43:10 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 9 Jan 2014 15:43:10 +0400 From: Gleb Smirnoff To: Guy Yur Subject: Re: 10.0-RC1, armv6: "pfctl -s state" crashes on BeagleBone Black due to unaligned access Message-ID: <20140109114310.GU71033@FreeBSD.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.22 (2013-10-16) Cc: freebsd-net@freebsd.org, freebsd-arm@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 09 Jan 2014 11:43:18 -0000 Guy, On Sat, Jan 04, 2014 at 03:06:02PM +0200, Guy Yur wrote: G> sizeof(struct pfsync_state_key) is 36 G> sizeof(struct pfsync_state_peer) is 32 G> sizeof(struct pf_addr) is 16 G> sizeof(struct pfsync_state) is 242 I am also afraid that the pfsync(4) itself isn't alignment safe. And receiving and processing a pfsync packet with couple of states would panic an arm box. Is it possible for you to check this? -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Thu Jan 9 14:29:43 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8BAAD27C; Thu, 9 Jan 2014 14:29:43 +0000 (UTC) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 537F219AA; Thu, 9 Jan 2014 14:29:43 +0000 (UTC) Received: by mail-pa0-f41.google.com with SMTP id fb1so1806364pad.0 for ; Thu, 09 Jan 2014 06:29:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=uiMWN5jR8dsST8Fyoc7iCFIDOG3Y13psOfpasyyJ9RE=; b=ihRUrAZ4vld8PwPj5IFhTZ81qrI7K3Ty5mfqYjfedA8gO+nkyNeG7XatS+/kiAnECz dy6mYLLJSCMikV++iHhnHGpxYi0QI/AHsmvUyBR9FTj2t9iTdEUghtnLiQLOvyobnuaY 6yOblnINkeaJftDwTuaaVgBojGQoeun32oxyREp2pPlvPZNF6Fe6SKFtNMjEUPUEK1mq maB51SS10MEJfWVVO95UhBI7Y3dPddE/5usHtNcUk10lu5/5hAXCGNwgPGhCYMCnM3np 9e/ueJHwwAIISU+7MLutInZmACjqvMorBJh7qt8jGbv6170kjAQ3vH08hqoPzAHZAJh+ zFFw== MIME-Version: 1.0 X-Received: by 10.69.12.99 with SMTP id ep3mr4128600pbd.86.1389277782965; Thu, 09 Jan 2014 06:29:42 -0800 (PST) Sender: ermal.luci@gmail.com Received: by 10.70.46.42 with HTTP; Thu, 9 Jan 2014 06:29:42 -0800 (PST) In-Reply-To: <20140109104223.GS71033@FreeBSD.org> References: <20140109104223.GS71033@FreeBSD.org> Date: Thu, 9 Jan 2014 15:29:42 +0100 X-Google-Sender-Auth: rwc266wx-fMYed7KwqO91Nco2B4 Message-ID: Subject: Re: 10.0-RC1, armv6: "pfctl -s state" crashes on BeagleBone Black due to unaligned access From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: Gleb Smirnoff Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-net , freebsd-arm@freebsd.org, Guy Yur X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 09 Jan 2014 14:29:43 -0000 On Thu, Jan 9, 2014 at 11:42 AM, Gleb Smirnoff wrote: > Guy, > > On Sat, Jan 04, 2014 at 03:06:02PM +0200, Guy Yur wrote: > G> I am running 10.0-RC1 arm.armv6 on the BeagleBone Black. > G> The "pfctl -s state" command is crashing when trying to print the > G> second entry. > G> > G> struct pfsync_state has a size that is not divisiable by 4 or 8 leading > to the > G> second entry in the returned state array not being aligned and pfctl > G> core dumps on Bus error when trying to access a uint32_t field. > G> > G> (gdb) bt > G> #0 print_host (addr=0x2085a11a, port=7660, af=2 '\002', opts=1024) at > G> /usr/src/sbin/pfctl/pf_print_state.c:178 > G> #1 0x00021c4c in print_state (s=0x2085a0f2, opts=1024) at > G> /usr/src/sbin/pfctl/pf_print_state.c:236 > G> #2 0x0000c664 in pfctl_show_states (dev=, > G> iface=0x0, opts=1024) at /usr/src/sbin/pfctl/pfctl.c:1095 > G> > G> sizeof(struct pfsync_state_key) is 36 > G> sizeof(struct pfsync_state_peer) is 32 > G> sizeof(struct pf_addr) is 16 > G> sizeof(struct pfsync_state) is 242 > G> > G> Removing the __spare[2] field will allow the struct to be aligned on 8 > bytes > G> for the u_int64_t id field and also cover the uint32_t fields alignment > G> but this will break KBI. > G> > G> I am currently using an inefficient workaround in pfctl_show_states > G> that memcpy each entry to a struct pfsync_state on the stack > G> ensuring each call to print_state receives an aligned struct. > G> > G> 10.0-RC1 World and kernel were compiled in a VirtualBox VM running > G> 9.2-RELEASE-p2 i386. > G> clang and ARM_EABI used as the default make options. > > For pf we are ready to break KBI. It uses same structs for internal kernel > representation and for ioctl() API and this is actually a bug. Until it is > properly fixed, we are doomed to break KBI always. > > Unfortunately, pfsync_state is not only a KBI but also a wire protocol for > pfsync(4). We can't break this, since that would make different FreeBSD > versions not exchanging states properly. > > Well, <= 8.x already is incompatible with >= 9.x, thanks yet another > OpenBSD > import. But we don't want to introduce another one. > > I will try to fix this making new structure for the ioctl. That will mean > moving slowly towards divorcing internal structures and ioctl ones. > > I'd appreciate if you file a PR on that, so that problem won't leave > forgotten > in the mailing list. You can even code the bugfix :) > > Thanks! > > Well pfsync has a version in its header so its quite possible to support many of them. > -- > Totus tuus, Glebius. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > -- Ermal From owner-freebsd-net@FreeBSD.ORG Thu Jan 9 15:39:49 2014 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9D1C849C; Thu, 9 Jan 2014 15:39:49 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6C0601125; Thu, 9 Jan 2014 15:39:49 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id s09Fdnlm056711; Thu, 9 Jan 2014 15:39:49 GMT (envelope-from ae@freefall.freebsd.org) Received: (from ae@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id s09Fdmub056710; Thu, 9 Jan 2014 15:39:48 GMT (envelope-from ae) Date: Thu, 9 Jan 2014 15:39:48 GMT Message-Id: <201401091539.s09Fdmub056710@freefall.freebsd.org> To: sven@vyatta.com, ae@FreeBSD.org, freebsd-net@FreeBSD.org, ae@FreeBSD.org From: ae@FreeBSD.org Subject: Re: kern/185148: [ip6] [patch] Cleanup ip6_mroute.c X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 09 Jan 2014 15:39:49 -0000 Synopsis: [ip6] [patch] Cleanup ip6_mroute.c State-Changed-From-To: open->patched State-Changed-By: ae State-Changed-When: Thu Jan 9 15:39:12 UTC 2014 State-Changed-Why: Patched in head/. Thanks! Responsible-Changed-From-To: freebsd-net->ae Responsible-Changed-By: ae Responsible-Changed-When: Thu Jan 9 15:39:12 UTC 2014 Responsible-Changed-Why: Take it. http://www.freebsd.org/cgi/query-pr.cgi?pr=185148 From owner-freebsd-net@FreeBSD.ORG Thu Jan 9 19:25:03 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5662974A; Thu, 9 Jan 2014 19:25:03 +0000 (UTC) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 1A4B515D3; Thu, 9 Jan 2014 19:25:02 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 4B6EE7300A; Thu, 9 Jan 2014 20:21:14 +0100 (CET) Date: Thu, 9 Jan 2014 20:21:14 +0100 From: Luigi Rizzo To: current@freebsd.org Subject: unused in_cksum_update() ? Message-ID: <20140109192114.GA49934@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Cc: net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 09 Jan 2014 19:25:03 -0000 a lot of arch-specific headers (sys/${ARCH}/include/in_cksum.h) have a lengthy definition for in_cksum_update(struct ip *ip) which seems completely unused in our source tree. Time to remove it perhaps ? grep cannot find any use at least since stable/8 cheers luigi From owner-freebsd-net@FreeBSD.ORG Thu Jan 9 21:27:53 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8F428716; Thu, 9 Jan 2014 21:27:53 +0000 (UTC) Received: from mail-qa0-x232.google.com (mail-qa0-x232.google.com [IPv6:2607:f8b0:400d:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3D04E1097; Thu, 9 Jan 2014 21:27:53 +0000 (UTC) Received: by mail-qa0-f50.google.com with SMTP id cm18so2083237qab.23 for ; Thu, 09 Jan 2014 13:27:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=3HYz8lPVWQGIKebxGcjIOjjG9vbJ8P1xbeyHU3CcGkQ=; b=DyLMBx7rm+oBheN0t0QrNZEqvyUUl8KVe3b4NzMf9attb1Byrw5JcPEGJlwdGVYfGw kbQM9Lahjz0c16m/xxWtx5aA35niVj8iMctGSZUJP3aDgMkL2k2HLKvGO+TZ2AV/WDpu ZbmZhneBg882I+QgSuZ1Dk231L1oLyzh82JAX8+QEyY52cw6348JigfqwtrlbwU0SoTj tysrlGX8V/ZRbg1y9BD0G4HGuRcmFDI8UkeC20l/5aUjZ97JEj9NsbWkNPdLf06wz+US zCli/X05HImL9P1i4fejHVWxvGbqvDO45ZBSPIlCSPevfVZA3sO4W7P/xB3rhGt4/oVW 71CA== MIME-Version: 1.0 X-Received: by 10.49.24.140 with SMTP id u12mr11973645qef.78.1389302872120; Thu, 09 Jan 2014 13:27:52 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.52.8 with HTTP; Thu, 9 Jan 2014 13:27:52 -0800 (PST) In-Reply-To: <20140109192114.GA49934@onelab2.iet.unipi.it> References: <20140109192114.GA49934@onelab2.iet.unipi.it> Date: Thu, 9 Jan 2014 13:27:52 -0800 X-Google-Sender-Auth: JA2p2h3MJ0WTfImVXkLXq5I0QmY Message-ID: Subject: Re: unused in_cksum_update() ? From: Adrian Chadd To: Luigi Rizzo Content-Type: text/plain; charset=ISO-8859-1 Cc: "current@freebsd.org" , "net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 09 Jan 2014 21:27:53 -0000 It's likely used elsewhere; it's the kind of thing you abuse when doing header rewriting and reinjection. So, what's the NAT and such code using? -a On 9 January 2014 11:21, Luigi Rizzo wrote: > a lot of arch-specific headers (sys/${ARCH}/include/in_cksum.h) > have a lengthy definition for > > in_cksum_update(struct ip *ip) > > which seems completely unused in our source tree. > Time to remove it perhaps ? > > grep cannot find any use at least since stable/8 > > cheers > luigi > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Thu Jan 9 21:40:55 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E8AA2DC; Thu, 9 Jan 2014 21:40:55 +0000 (UTC) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id A5A39120F; Thu, 9 Jan 2014 21:40:55 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 3056C7300A; Thu, 9 Jan 2014 22:43:09 +0100 (CET) Date: Thu, 9 Jan 2014 22:43:09 +0100 From: Luigi Rizzo To: Adrian Chadd Subject: Re: unused in_cksum_update() ? Message-ID: <20140109214309.GA51309@onelab2.iet.unipi.it> References: <20140109192114.GA49934@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "current@freebsd.org" , "net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 09 Jan 2014 21:40:56 -0000 On Thu, Jan 09, 2014 at 01:27:52PM -0800, Adrian Chadd wrote: > It's likely used elsewhere; it's the kind of thing you abuse when > doing header rewriting and reinjection. So, what's the NAT and such > code using? natd/libalias has its own code with a DifferentialChecksum() function in sys/netinet/libalias/alias_util.c which adds and subtracts the chunks in the old and new packet. ip_fastfwd.c does it inline: /* * Decrement the TTL and incrementally change the IP header checksum. * Don't bother doing this with hw checksum offloading, it's faster * doing it right here. */ ip->ip_ttl -= IPTTLDEC; if (ip->ip_sum >= (u_int16_t) ~htons(IPTTLDEC << 8)) ip->ip_sum -= ~htons(IPTTLDEC << 8); else ip->ip_sum += htons(IPTTLDEC << 8); ip_forward() relies on the recomputation done in ip_output(). And there is no trace of in_cksum_update() in the entire source tree apart from its definition. cheers luigi From owner-freebsd-net@FreeBSD.ORG Thu Jan 9 22:17:13 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8B96EFB8; Thu, 9 Jan 2014 22:17:13 +0000 (UTC) Received: from mail-oa0-x233.google.com (mail-oa0-x233.google.com [IPv6:2607:f8b0:4003:c02::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3A7CE1509; Thu, 9 Jan 2014 22:17:13 +0000 (UTC) Received: by mail-oa0-f51.google.com with SMTP id m1so4138094oag.24 for ; Thu, 09 Jan 2014 14:17:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=d6OF2dt4gC2ZXrs+CdrqbvQa/AqP2T3QhBp8lcCF55I=; b=p3tNvc3F1jxp4ays/DLgj+IHafANlxpXPrdS9Jn6ZAv8DTduSScRfcggm8nKvfAFUV EdFgOIUBMETJH2UU05uMmVticEyFHv6gwgh0IxLtS09TMoCYufyZdKaqp2dyCpTmJiZK V81BfzTsiQW/44As/tW7luciMJpTK8FZgx/xlmaxMIh+aOnfDBItGzjEDfTxpfHAlZwy H6bbbm/IFQkF14PlmiSxY7nJmHYbr/JtzrcfsLmFzmew3Im6PGamYgDr7Lq2+VXPgBkJ Z+f3LieJVkgZRSR/qaEUIlh7Qk2Yrq2GYsFUavrcMfYeAQqX2qTOOON9UlWfowCzjsLe jqTQ== MIME-Version: 1.0 X-Received: by 10.182.221.230 with SMTP id qh6mr4225814obc.7.1389305832460; Thu, 09 Jan 2014 14:17:12 -0800 (PST) Received: by 10.76.20.82 with HTTP; Thu, 9 Jan 2014 14:17:12 -0800 (PST) In-Reply-To: <20140109104223.GS71033@FreeBSD.org> References: <20140109104223.GS71033@FreeBSD.org> Date: Fri, 10 Jan 2014 00:17:12 +0200 Message-ID: Subject: Re: 10.0-RC1, armv6: "pfctl -s state" crashes on BeagleBone Black due to unaligned access From: Guy Yur To: Gleb Smirnoff Content-Type: text/plain; charset=UTF-8 Cc: freebsd-net@freebsd.org, freebsd-arm@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 09 Jan 2014 22:17:13 -0000 Hi, On Thu, Jan 9, 2014 at 12:42 PM, Gleb Smirnoff wrote: > Guy, > > On Sat, Jan 04, 2014 at 03:06:02PM +0200, Guy Yur wrote: > G> I am running 10.0-RC1 arm.armv6 on the BeagleBone Black. > G> The "pfctl -s state" command is crashing when trying to print the > G> second entry. > G> > G> (gdb) bt > G> #0 print_host (addr=0x2085a11a, port=7660, af=2 '\002', opts=1024) at > G> /usr/src/sbin/pfctl/pf_print_state.c:178 > G> #1 0x00021c4c in print_state (s=0x2085a0f2, opts=1024) at > G> /usr/src/sbin/pfctl/pf_print_state.c:236 > G> #2 0x0000c664 in pfctl_show_states (dev=, > G> iface=0x0, opts=1024) at /usr/src/sbin/pfctl/pfctl.c:1095 > G> > G> sizeof(struct pfsync_state_key) is 36 > G> sizeof(struct pfsync_state_peer) is 32 > G> sizeof(struct pf_addr) is 16 > G> sizeof(struct pfsync_state) is 242 > G> > > I will try to fix this making new structure for the ioctl. That will mean > moving slowly towards divorcing internal structures and ioctl ones. > > I'd appreciate if you file a PR on that, so that problem won't leave forgotten > in the mailing list. You can even code the bugfix :) > > Thanks! > > -- > Totus tuus, Glebius. I filled arm/185617 with some updated information. After further looking at why the kernel doesn't crash when filling the pfsync_state array and only the userspace pfctl is crashing I see that pfsync_state has the __packed attribute which means on arm unaligned access is used so there is no problem handling an unaligned pfsync_state. The reason pfctl crashes is because it passes a structure field as a pf_addr pointer. struct pf_addr is not __packed so on arm word access will be used, triggering the unaligned fault. So there is indeed no need to break the pfsync protocol. In if_pfsync.c I think all the accesses to pfsync_state are done using a pfsync_state pointer, there is no passing of struct fields as separate pointers and since the struct is covered by __packed there won't be an unaligned access. Thanks, Guy From owner-freebsd-net@FreeBSD.ORG Thu Jan 9 22:26:11 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C4D07366; Thu, 9 Jan 2014 22:26:11 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9B7A715CD; Thu, 9 Jan 2014 22:26:11 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s09MQAGw058049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Jan 2014 14:26:10 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s09MQAlA058048; Thu, 9 Jan 2014 14:26:10 -0800 (PST) (envelope-from jmg) Date: Thu, 9 Jan 2014 14:26:10 -0800 From: John-Mark Gurney To: Guy Yur Subject: Re: 10.0-RC1, armv6: "pfctl -s state" crashes on BeagleBone Black due to unaligned access Message-ID: <20140109222610.GJ46596@funkthat.com> Mail-Followup-To: Guy Yur , Gleb Smirnoff , freebsd-net@freebsd.org, freebsd-arm@freebsd.org References: <20140109104223.GS71033@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Thu, 09 Jan 2014 14:26:10 -0800 (PST) Cc: freebsd-net@freebsd.org, freebsd-arm@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 09 Jan 2014 22:26:11 -0000 Guy Yur wrote this message on Fri, Jan 10, 2014 at 00:17 +0200: > On Thu, Jan 9, 2014 at 12:42 PM, Gleb Smirnoff wrote: > > Guy, > > > > On Sat, Jan 04, 2014 at 03:06:02PM +0200, Guy Yur wrote: > > G> I am running 10.0-RC1 arm.armv6 on the BeagleBone Black. > > G> The "pfctl -s state" command is crashing when trying to print the > > G> second entry. > > > G> > > G> (gdb) bt > > G> #0 print_host (addr=0x2085a11a, port=7660, af=2 '\002', opts=1024) at > > G> /usr/src/sbin/pfctl/pf_print_state.c:178 > > G> #1 0x00021c4c in print_state (s=0x2085a0f2, opts=1024) at > > G> /usr/src/sbin/pfctl/pf_print_state.c:236 > > G> #2 0x0000c664 in pfctl_show_states (dev=, > > G> iface=0x0, opts=1024) at /usr/src/sbin/pfctl/pfctl.c:1095 > > G> > > G> sizeof(struct pfsync_state_key) is 36 > > G> sizeof(struct pfsync_state_peer) is 32 > > G> sizeof(struct pf_addr) is 16 > > G> sizeof(struct pfsync_state) is 242 > > G> > > > > > I will try to fix this making new structure for the ioctl. That will mean > > moving slowly towards divorcing internal structures and ioctl ones. > > > > I'd appreciate if you file a PR on that, so that problem won't leave forgotten > > in the mailing list. You can even code the bugfix :) > > > > Thanks! > > > > -- > > Totus tuus, Glebius. > > I filled arm/185617 with some updated information. > > After further looking at why the kernel doesn't crash when filling > the pfsync_state array and only the userspace pfctl is crashing I > see that pfsync_state has the __packed attribute which means on arm > unaligned access is used so there is no problem handling an unaligned > pfsync_state. > > The reason pfctl crashes is because it passes a structure field > as a pf_addr pointer. struct pf_addr is not __packed so on arm > word access will be used, triggering the unaligned fault. > > So there is indeed no need to break the pfsync protocol. > > In if_pfsync.c I think all the accesses to pfsync_state are done using > a pfsync_state pointer, there is no passing of struct fields as > separate pointers and since the struct is covered by __packed > there won't be an unaligned access. Ok, that makes sense... so, either we mark struct pf_addr as __packed, or we do some nasty stuff, like the following in print_host: struct { struct pf_addr a } *uaddr __packed; uaddr = addr; aw.v.a.addr = uaddr->a; it's not pretty, but I believe it would work... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-net@FreeBSD.ORG Thu Jan 9 23:04:58 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C1A0D380; Thu, 9 Jan 2014 23:04:58 +0000 (UTC) Received: from mail-oa0-x233.google.com (mail-oa0-x233.google.com [IPv6:2607:f8b0:4003:c02::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6B61818A9; Thu, 9 Jan 2014 23:04:58 +0000 (UTC) Received: by mail-oa0-f51.google.com with SMTP id m1so4188985oag.24 for ; Thu, 09 Jan 2014 15:04:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=kaghnQjANnNR0a9EpS6wbhrcoDcotmOGxSD7iava9U4=; b=Pb2OMVmCe7iPQ8sn2LvzrKzfbOszsvnrd1vSttKWVisBapudwP88tFHz/Pkhswp2g0 T3XGpZEjuOe+f0bpysdpNW7/av8yePVOtz4eYL6fFlfCwtOxywxnK2/Not9jtDzlt59z EpZAVPcI50SfXsUJwHDZfxteLudFeVm35vlmGvNauI93RlMDZ7gF316W/QHR38Ij2C/U Zi0pPYyrvNRVs1oJUWNcbCcG8p9vlOBgcY9qyGDVGg/npf2x5vCUzDJa9/U1feZd4uqr hQISnMzqLhqmGFcmAtkYIoyg5Helwogohpf3qKvnvfVEov2aIq5x8cBN1o18s+JEConR JNgA== MIME-Version: 1.0 X-Received: by 10.60.179.113 with SMTP id df17mr4501215oec.16.1389308697685; Thu, 09 Jan 2014 15:04:57 -0800 (PST) Received: by 10.76.20.82 with HTTP; Thu, 9 Jan 2014 15:04:57 -0800 (PST) In-Reply-To: <20140109222610.GJ46596@funkthat.com> References: <20140109104223.GS71033@FreeBSD.org> <20140109222610.GJ46596@funkthat.com> Date: Fri, 10 Jan 2014 01:04:57 +0200 Message-ID: Subject: Re: 10.0-RC1, armv6: "pfctl -s state" crashes on BeagleBone Black due to unaligned access From: Guy Yur To: Guy Yur , Gleb Smirnoff , freebsd-net@freebsd.org, freebsd-arm@freebsd.org Content-Type: multipart/mixed; boundary=089e011609bc6931ef04ef91a33c X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 09 Jan 2014 23:04:58 -0000 --089e011609bc6931ef04ef91a33c Content-Type: text/plain; charset=UTF-8 On Fri, Jan 10, 2014 at 12:26 AM, John-Mark Gurney wrote: > Guy Yur wrote this message on Fri, Jan 10, 2014 at 00:17 +0200: >> On Thu, Jan 9, 2014 at 12:42 PM, Gleb Smirnoff wrote: >> > Guy, >> > >> > On Sat, Jan 04, 2014 at 03:06:02PM +0200, Guy Yur wrote: >> > G> I am running 10.0-RC1 arm.armv6 on the BeagleBone Black. >> > G> The "pfctl -s state" command is crashing when trying to print the >> > G> second entry. >> > Ok, that makes sense... so, either we mark struct pf_addr as __packed, > or we do some nasty stuff, like the following in print_host: > struct { > struct pf_addr a > } *uaddr __packed; > > uaddr = addr; > aw.v.a.addr = uaddr->a; > > it's not pretty, but I believe it would work... > > -- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." For performance reasons, I don't think pf_addr should be marked as __packed. I attached the changes I am now using in print_state() since there is no need to copy the full pfsync_state, only pf_addr. I converted sk and nk from pointers to structs on the stack and using struct copy. pf_addr is 16 bytes. Regards, Guy --089e011609bc6931ef04ef91a33c Content-Type: application/octet-stream; name="pf_print_state.patch" Content-Disposition: attachment; filename="pf_print_state.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hq8m4iyt0 SW5kZXg6IHBmY3RsL3BmX3ByaW50X3N0YXRlLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gcGZjdGwvcGZfcHJp bnRfc3RhdGUuYwkocmV2aXNpb24gMjYwNDkyKQorKysgcGZjdGwvcGZfcHJpbnRfc3RhdGUuYwko d29ya2luZyBjb3B5KQpAQCAtMjA4LDcgKzIwOCw3IEBAIHZvaWQKIHByaW50X3N0YXRlKHN0cnVj dCBwZnN5bmNfc3RhdGUgKnMsIGludCBvcHRzKQogewogCXN0cnVjdCBwZnN5bmNfc3RhdGVfcGVl ciAqc3JjLCAqZHN0OwotCXN0cnVjdCBwZnN5bmNfc3RhdGVfa2V5ICpzaywgKm5rOworCXN0cnVj dCBwZnN5bmNfc3RhdGVfa2V5IHNrLCBuazsKIAlzdHJ1Y3QgcHJvdG9lbnQgKnA7CiAJaW50IG1p biwgc2VjOwogCkBAIC0yMTUsMTcgKzIxNSwxNyBAQCBwcmludF9zdGF0ZShzdHJ1Y3QgcGZzeW5j X3N0YXRlICpzLCBpbnQgb3B0cykKIAlpZiAocy0+ZGlyZWN0aW9uID09IFBGX09VVCkgewogCQlz cmMgPSAmcy0+c3JjOwogCQlkc3QgPSAmcy0+ZHN0OwotCQlzayA9ICZzLT5rZXlbUEZfU0tfU1RB Q0tdOwotCQluayA9ICZzLT5rZXlbUEZfU0tfV0lSRV07CisJCXNrID0gcy0+a2V5W1BGX1NLX1NU QUNLXTsKKwkJbmsgPSBzLT5rZXlbUEZfU0tfV0lSRV07CiAJCWlmIChzLT5wcm90byA9PSBJUFBS T1RPX0lDTVAgfHwgcy0+cHJvdG8gPT0gSVBQUk9UT19JQ01QVjYpIAotCQkJc2stPnBvcnRbMF0g PSBuay0+cG9ydFswXTsKKwkJCXNrLnBvcnRbMF0gPSBuay5wb3J0WzBdOwogCX0gZWxzZSB7CiAJ CXNyYyA9ICZzLT5kc3Q7CiAJCWRzdCA9ICZzLT5zcmM7Ci0JCXNrID0gJnMtPmtleVtQRl9TS19X SVJFXTsKLQkJbmsgPSAmcy0+a2V5W1BGX1NLX1NUQUNLXTsKKwkJc2sgPSBzLT5rZXlbUEZfU0tf V0lSRV07CisJCW5rID0gcy0+a2V5W1BGX1NLX1NUQUNLXTsKIAkJaWYgKHMtPnByb3RvID09IElQ UFJPVE9fSUNNUCB8fCBzLT5wcm90byA9PSBJUFBST1RPX0lDTVBWNikgCi0JCQlzay0+cG9ydFsx XSA9IG5rLT5wb3J0WzFdOworCQkJc2sucG9ydFsxXSA9IG5rLnBvcnRbMV07CiAJfQogCXByaW50 ZigiJXMgIiwgcy0+aWZuYW1lKTsKIAlpZiAoKHAgPSBnZXRwcm90b2J5bnVtYmVyKHMtPnByb3Rv KSkgIT0gTlVMTCkKQEAgLTIzMywxMSArMjMzLDExIEBAIHByaW50X3N0YXRlKHN0cnVjdCBwZnN5 bmNfc3RhdGUgKnMsIGludCBvcHRzKQogCWVsc2UKIAkJcHJpbnRmKCIldSAiLCBzLT5wcm90byk7 CiAKLQlwcmludF9ob3N0KCZuay0+YWRkclsxXSwgbmstPnBvcnRbMV0sIHMtPmFmLCBvcHRzKTsK LQlpZiAoUEZfQU5FUSgmbmstPmFkZHJbMV0sICZzay0+YWRkclsxXSwgcy0+YWYpIHx8Ci0JICAg IG5rLT5wb3J0WzFdICE9IHNrLT5wb3J0WzFdKSB7CisJcHJpbnRfaG9zdCgmbmsuYWRkclsxXSwg bmsucG9ydFsxXSwgcy0+YWYsIG9wdHMpOworCWlmIChQRl9BTkVRKCZuay5hZGRyWzFdLCAmc2su YWRkclsxXSwgcy0+YWYpIHx8CisJICAgIG5rLnBvcnRbMV0gIT0gc2sucG9ydFsxXSkgewogCQlw cmludGYoIiAoIik7Ci0JCXByaW50X2hvc3QoJnNrLT5hZGRyWzFdLCBzay0+cG9ydFsxXSwgcy0+ YWYsIG9wdHMpOworCQlwcmludF9ob3N0KCZzay5hZGRyWzFdLCBzay5wb3J0WzFdLCBzLT5hZiwg b3B0cyk7CiAJCXByaW50ZigiKSIpOwogCX0KIAlpZiAocy0+ZGlyZWN0aW9uID09IFBGX09VVCkK QEAgLTI0NCwxMSArMjQ0LDExIEBAIHByaW50X3N0YXRlKHN0cnVjdCBwZnN5bmNfc3RhdGUgKnMs IGludCBvcHRzKQogCQlwcmludGYoIiAtPiAiKTsKIAllbHNlCiAJCXByaW50ZigiIDwtICIpOwot CXByaW50X2hvc3QoJm5rLT5hZGRyWzBdLCBuay0+cG9ydFswXSwgcy0+YWYsIG9wdHMpOwotCWlm IChQRl9BTkVRKCZuay0+YWRkclswXSwgJnNrLT5hZGRyWzBdLCBzLT5hZikgfHwKLQkgICAgbmst PnBvcnRbMF0gIT0gc2stPnBvcnRbMF0pIHsKKwlwcmludF9ob3N0KCZuay5hZGRyWzBdLCBuay5w b3J0WzBdLCBzLT5hZiwgb3B0cyk7CisJaWYgKFBGX0FORVEoJm5rLmFkZHJbMF0sICZzay5hZGRy WzBdLCBzLT5hZikgfHwKKwkgICAgbmsucG9ydFswXSAhPSBzay5wb3J0WzBdKSB7CiAJCXByaW50 ZigiICgiKTsKLQkJcHJpbnRfaG9zdCgmc2stPmFkZHJbMF0sIHNrLT5wb3J0WzBdLCBzLT5hZiwg b3B0cyk7CisJCXByaW50X2hvc3QoJnNrLmFkZHJbMF0sIHNrLnBvcnRbMF0sIHMtPmFmLCBvcHRz KTsKIAkJcHJpbnRmKCIpIik7CiAJfQogCg== --089e011609bc6931ef04ef91a33c-- From owner-freebsd-net@FreeBSD.ORG Thu Jan 9 23:39:00 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0D91A12B; Thu, 9 Jan 2014 23:39:00 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D807E1AEE; Thu, 9 Jan 2014 23:38:59 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s09Ncwm9059056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Jan 2014 15:38:59 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s09Ncwe2059055; Thu, 9 Jan 2014 15:38:58 -0800 (PST) (envelope-from jmg) Date: Thu, 9 Jan 2014 15:38:58 -0800 From: John-Mark Gurney To: Guy Yur Subject: Re: 10.0-RC1, armv6: "pfctl -s state" crashes on BeagleBone Black due to unaligned access Message-ID: <20140109233858.GL46596@funkthat.com> Mail-Followup-To: Guy Yur , Gleb Smirnoff , freebsd-net@freebsd.org, freebsd-arm@freebsd.org References: <20140109104223.GS71033@FreeBSD.org> <20140109222610.GJ46596@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Thu, 09 Jan 2014 15:38:59 -0800 (PST) Cc: freebsd-net@freebsd.org, freebsd-arm@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 09 Jan 2014 23:39:00 -0000 Guy Yur wrote this message on Fri, Jan 10, 2014 at 01:04 +0200: > On Fri, Jan 10, 2014 at 12:26 AM, John-Mark Gurney wrote: > > Guy Yur wrote this message on Fri, Jan 10, 2014 at 00:17 +0200: > >> On Thu, Jan 9, 2014 at 12:42 PM, Gleb Smirnoff wrote: > >> > Guy, > >> > > >> > On Sat, Jan 04, 2014 at 03:06:02PM +0200, Guy Yur wrote: > >> > G> I am running 10.0-RC1 arm.armv6 on the BeagleBone Black. > >> > G> The "pfctl -s state" command is crashing when trying to print the > >> > G> second entry. > >> > > > Ok, that makes sense... so, either we mark struct pf_addr as __packed, > > or we do some nasty stuff, like the following in print_host: > > struct { > > struct pf_addr a > > } *uaddr __packed; > > > > uaddr = addr; > > aw.v.a.addr = uaddr->a; > > > > it's not pretty, but I believe it would work... > > For performance reasons, I don't think pf_addr should be marked as __packed. > > I attached the changes I am now using in print_state() since there is > no need to copy > the full pfsync_state, only pf_addr. > I converted sk and nk from pointers to structs on the stack and using > struct copy. > pf_addr is 16 bytes. Did you look at using the above trick? Since we are iterating over a list, that'll be a lot of copies, plus, I'm not sure that your fix will be guaranteed to work for ever.. since there isn't a requirement that the copy happens w/ bcopy/memcpy or some other copy routine that assumes things might not be aligned... Specificly these: - sk = &s->key[PF_SK_STACK]; - nk = &s->key[PF_SK_WIRE]; + sk = s->key[PF_SK_STACK]; + nk = s->key[PF_SK_WIRE]; since s->key is already assumed to be aligned, a future compiler could be smart enough to say, I'm not going to use the stack.. That would/could happen if print_host's addr arg grew a const which it could... Also, I just realized that some of the lines modify sk (setting port), but you don't write those modifications back to s->key[PF_SK_STACK]... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-net@FreeBSD.ORG Fri Jan 10 10:31:56 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E30D5854; Fri, 10 Jan 2014 10:31:56 +0000 (UTC) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6D1931E1A; Fri, 10 Jan 2014 10:31:55 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.7/8.14.7) with ESMTP id s0AAVeoQ033502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 10 Jan 2014 14:31:40 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.7/8.14.7/Submit) id s0AAVeW0033501; Fri, 10 Jan 2014 14:31:40 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 10 Jan 2014 14:31:40 +0400 From: Gleb Smirnoff To: Luigi Rizzo Subject: Re: unused in_cksum_update() ? Message-ID: <20140110103140.GD73147@FreeBSD.org> References: <20140109192114.GA49934@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140109192114.GA49934@onelab2.iet.unipi.it> User-Agent: Mutt/1.5.22 (2013-10-16) Cc: current@freebsd.org, net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 10 Jan 2014 10:31:57 -0000 On Thu, Jan 09, 2014 at 08:21:14PM +0100, Luigi Rizzo wrote: L> a lot of arch-specific headers (sys/${ARCH}/include/in_cksum.h) L> have a lengthy definition for L> L> in_cksum_update(struct ip *ip) L> L> which seems completely unused in our source tree. L> Time to remove it perhaps ? L> L> grep cannot find any use at least since stable/8 I'd prefer not to hurry with its removal. Might be that pf will use it. Since it lives in a header file, it doesn't add a single bit to kernel size. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Fri Jan 10 11:56:34 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E8729E81; Fri, 10 Jan 2014 11:56:33 +0000 (UTC) Received: from mail-oa0-x22e.google.com (mail-oa0-x22e.google.com [IPv6:2607:f8b0:4003:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9DD74152D; Fri, 10 Jan 2014 11:56:33 +0000 (UTC) Received: by mail-oa0-f46.google.com with SMTP id l6so4849351oag.19 for ; Fri, 10 Jan 2014 03:56:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=sLUlKQy0MoIiYGhsbK3mHa3pgCcUvH7CqSp3nhZhKa0=; b=dvGRpu/ULv0x1ynxhtYNNwFCC8V/lsirExSkHf3mm8UerHprJPcM+N9KRtYRiUUR+D xTOTcMIqREmUaasz769unCrgKXDBCpZ/sDQesASfYhZSnUbSYDRyvACb5GTPyrwfqEk2 KyuzQNybPlKQrleEhclLPa6ai+ko07qRXczMinklJ1mZu1kk5o+Oil9QuIxAES/iZKF0 WDpoJ+GMsH/OAT9qFMVAdyeaJcOZNuOsaKObufUIsgN2NYZQq3Qt8n0TwCx4BDCs94g4 MrdjDNImfdZXVAMATXPZlwMel7JQGbdfBTw6b/pC93LosJLticcwreQ/Eo8/60cLkfXl nvkw== MIME-Version: 1.0 X-Received: by 10.60.62.199 with SMTP id a7mr1778866oes.64.1389354992911; Fri, 10 Jan 2014 03:56:32 -0800 (PST) Received: by 10.76.20.82 with HTTP; Fri, 10 Jan 2014 03:56:32 -0800 (PST) In-Reply-To: <20140109233858.GL46596@funkthat.com> References: <20140109104223.GS71033@FreeBSD.org> <20140109222610.GJ46596@funkthat.com> <20140109233858.GL46596@funkthat.com> Date: Fri, 10 Jan 2014 13:56:32 +0200 Message-ID: Subject: Re: 10.0-RC1, armv6: "pfctl -s state" crashes on BeagleBone Black due to unaligned access From: Guy Yur To: freebsd-net@freebsd.org, freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 10 Jan 2014 11:56:34 -0000 On Fri, Jan 10, 2014 at 1:38 AM, John-Mark Gurney wrote: > Guy Yur wrote this message on Fri, Jan 10, 2014 at 01:04 +0200: >> On Fri, Jan 10, 2014 at 12:26 AM, John-Mark Gurney wrote: >> > Guy Yur wrote this message on Fri, Jan 10, 2014 at 00:17 +0200: >> >> On Thu, Jan 9, 2014 at 12:42 PM, Gleb Smirnoff wrote: >> >> > Guy, >> >> > >> >> > On Sat, Jan 04, 2014 at 03:06:02PM +0200, Guy Yur wrote: >> >> > G> I am running 10.0-RC1 arm.armv6 on the BeagleBone Black. >> >> > G> The "pfctl -s state" command is crashing when trying to print the >> >> > G> second entry. >> >> >> >> > Ok, that makes sense... so, either we mark struct pf_addr as __packed, >> > or we do some nasty stuff, like the following in print_host: >> > struct { >> > struct pf_addr a >> > } *uaddr __packed; >> > >> > uaddr = addr; >> > aw.v.a.addr = uaddr->a; >> > >> > it's not pretty, but I believe it would work... >> >> For performance reasons, I don't think pf_addr should be marked as __packed. >> >> I attached the changes I am now using in print_state() since there is >> no need to copy >> the full pfsync_state, only pf_addr. >> I converted sk and nk from pointers to structs on the stack and using >> struct copy. >> pf_addr is 16 bytes. > > Did you look at using the above trick? > > Since we are iterating over a list, that'll be a lot of copies, plus, > I'm not sure that your fix will be guaranteed to work for ever.. since > there isn't a requirement that the copy happens w/ bcopy/memcpy or some > other copy routine that assumes things might not be aligned... > Right. The correct fix would be to have a separate struct for the ioctl that can be aligned as Gleb suggested. I will try to prepare and test such changes. If new ioctls are added, the KBI can also be preserved. pfsync_state_export is used by if_pfsync.c and pf_ioctl.c so there will be duplicated code even if reusing the old ioctls with the new struct. > Specificly these: > - sk = &s->key[PF_SK_STACK]; > - nk = &s->key[PF_SK_WIRE]; > + sk = s->key[PF_SK_STACK]; > + nk = s->key[PF_SK_WIRE]; > > since s->key is already assumed to be aligned, a future compiler could > be smart enough to say, I'm not going to use the stack.. That > would/could happen if print_host's addr arg grew a const which it > could... > I thought that because s itself is __packed and key is an array inside s the __packed will apply to it too, since the disassembly showed clang chose to do a memcpy, I don't know if that is true or not. An explicit bcopy is safer. I see that the function already does a bcopy of the u_int64_t id field so it has some assumption that the structure might not be aligned. If a new always aligned structure is used for the ioctl, the bcopy of id can also be avoided. > Also, I just realized that some of the lines modify sk (setting port), > but you don't write those modifications back to s->key[PF_SK_STACK]... > The print function doesn't need to modify s->key, the port changes are only for passing to print_host. > -- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." Regards, Guy From owner-freebsd-net@FreeBSD.ORG Fri Jan 10 18:22:39 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8D7C19CB; Fri, 10 Jan 2014 18:22:39 +0000 (UTC) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 0D44F12C8; Fri, 10 Jan 2014 18:22:33 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 93EFB7300A; Fri, 10 Jan 2014 19:24:48 +0100 (CET) Date: Fri, 10 Jan 2014 19:24:48 +0100 From: Luigi Rizzo To: Gleb Smirnoff , wollman@freebsd.org Subject: Re: unused in_cksum_update() ? Message-ID: <20140110182448.GA62317@onelab2.iet.unipi.it> References: <20140109192114.GA49934@onelab2.iet.unipi.it> <20140110103140.GD73147@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140110103140.GD73147@FreeBSD.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: current@freebsd.org, net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 10 Jan 2014 18:22:39 -0000 On Fri, Jan 10, 2014 at 02:31:40PM +0400, Gleb Smirnoff wrote: > On Thu, Jan 09, 2014 at 08:21:14PM +0100, Luigi Rizzo wrote: > L> a lot of arch-specific headers (sys/${ARCH}/include/in_cksum.h) > L> have a lengthy definition for > L> > L> in_cksum_update(struct ip *ip) > L> > L> which seems completely unused in our source tree. > L> Time to remove it perhaps ? > L> > L> grep cannot find any use at least since stable/8 > > I'd prefer not to hurry with its removal. Might be that pf will use it. > Since it lives in a header file, it doesn't add a single bit to kernel > size. we should care more about obfuscation and correcteness, and this is a killer in both respects. Depending on $arch the function is not even available or wrong: In particular, the basic code follows the description in http://tools.ietf.org/html/rfc1141A with ntohs/htons to deal with endianness (note that the '256' should not be converted): tmp = ntohs(sum)+256; tmp = tmp + (tmp >> 16); sum = htons(tmp); // also truncates high bits It is correctly implemented (but in a totally generic way, so no point to have it in the arch-specific files) for amd64, i386, ia64, mips, powerpc; it is not implemented for arm, and it is wrong for sparc64 (where the 256 is incorrectly replaced by a 1). In terms of usage: the svn repo suggests that it was added in r15884 in 1996 (stable/2.2 is the first branch where it appears): http://svnweb.freebsd.org/base/head/sys/i386/include/in_cksum.h?r1=15884&r2=15883&pathrev=15884 as far as i can tell never used anywhere, and copied from place to place when we started to support different architectures. Shall we wait until it becomes 18 ? :) I am adding Garret to the list as he may have more details. cheers luigi From owner-freebsd-net@FreeBSD.ORG Sat Jan 11 12:05:35 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 08A04602 for ; Sat, 11 Jan 2014 12:05:35 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id C33441DEC for ; Sat, 11 Jan 2014 12:05:34 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:9cb5:5294:4115:885b]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 9088B4AC2D for ; Sat, 11 Jan 2014 16:05:33 +0400 (MSK) Date: Sat, 11 Jan 2014 16:05:25 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1063008459.20140111160525@serebryakov.spb.ru> To: net@freebsd.org Subject: Merge ping+ping6 and traceroue+traceroute6 to single utilities? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jan 2014 12:05:35 -0000 Hello, Net. Is here any project to merge ping/ping6 into ping and traceroute/traceroute6 into treaceroute? As IPv6 becomes more common these days, it is very inconvenient to have these utilities separated. -- // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Sat Jan 11 13:04:06 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 033A1155; Sat, 11 Jan 2014 13:04:06 +0000 (UTC) Received: from mail.tyknet.dk (mail.tyknet.dk [IPv6:2a01:4f8:201:2327:144:76:253:226]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B5A7B11AD; Sat, 11 Jan 2014 13:04:05 +0000 (UTC) Received: from [10.10.1.214] (217.71.4.82.static.router4.bolignet.dk [217.71.4.82]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.tyknet.dk (Postfix) with ESMTPSA id C910918733E; Sat, 11 Jan 2014 13:04:03 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail.tyknet.dk C910918733E DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=gibfest.dk; s=default; t=1389445443; bh=UJvEDyDIlCjvoGZ6catqZ0xXwAyT3TQNufKZNiXSKXI=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=ozguOUN7tsahSC2gVIfLjefyvSw5/3nATCO+zTwAOSyWcqwwHNjYlNFIJQlS6X3dO AOjZTy4AovMFI28f1r7ffZhbZw9iso5fzcUeS5zEpqYZqM8p68/7ntGFoyhtyTwXqo oYdTRuK8mFzcynJYeFR3cJMiMtoXkp6ny4fYEaLw= Message-ID: <52D14140.3090003@gibfest.dk> Date: Sat, 11 Jan 2014 14:04:00 +0100 From: Thomas Steen Rasmussen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: lev@FreeBSD.org Subject: Re: Merge ping+ping6 and traceroue+traceroute6 to single utilities? References: <1063008459.20140111160525@serebryakov.spb.ru> In-Reply-To: <1063008459.20140111160525@serebryakov.spb.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 11 Jan 2014 13:04:06 -0000 On 11-01-2014 13:05, Lev Serebryakov wrote: > Hello, Net. > > Is here any project to merge ping/ping6 into ping and > traceroute/traceroute6 into treaceroute? As IPv6 becomes more common these > days, it is very inconvenient to have these utilities separated. > Hello, I hope not, these should remain seperate, allow me to explain: There is a good reason these utilities are seperated into v4 and v6 specific versions, while other tools support both. The reason is that ping and traceroute are network troubleshooting utilities that are only used for verifying/testing network connectivity. When testing network connectivity you are usually thinking about a specific protocol. Having seperate versions of the tools removes the ambiguity for hostnames with both A and AAAA records. If you want to test v4, use ping, if you want to test v6, use ping6. Normal network enabled utilities like telnet or ftp or nc support both because when using those you usually don't care about the address family used, you just want to connect. This is a significant difference from using ping or traceroute where you almost always want a specific address family, depending on what you are testing. Make sense ? Best regards Thomas Steen Rasmussen From owner-freebsd-net@FreeBSD.ORG Sat Jan 11 13:19:57 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 28456280; Sat, 11 Jan 2014 13:19:57 +0000 (UTC) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F38B2123A; Sat, 11 Jan 2014 13:19:55 +0000 (UTC) Received: from [172.16.25.100] (69-77-129-4.static.skybest.com [69.77.129.4]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 45179BC3; Sat, 11 Jan 2014 08:14:17 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: Merge ping+ping6 and traceroue+traceroute6 to single utilities? From: Tom Pusateri In-Reply-To: <52D14140.3090003@gibfest.dk> Date: Sat, 11 Jan 2014 08:14:18 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <1879F103-99ED-479C-8B2F-4970A79A9573@bangj.com> References: <1063008459.20140111160525@serebryakov.spb.ru> <52D14140.3090003@gibfest.dk> To: Thomas Steen Rasmussen X-Mailer: Apple Mail (2.1827) Cc: lev@FreeBSD.org, net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 11 Jan 2014 13:19:57 -0000 On Jan 11, 2014, at 8:04 AM, Thomas Steen Rasmussen = wrote: > On 11-01-2014 13:05, Lev Serebryakov wrote: >> Hello, Net. >>=20 >> Is here any project to merge ping/ping6 into ping and >> traceroute/traceroute6 into treaceroute? As IPv6 becomes more common = these >> days, it is very inconvenient to have these utilities separated. >>=20 > Hello, >=20 > I hope not, these should remain seperate, allow me to explain: >=20 > There is a good reason these utilities are seperated into v4 and > v6 specific versions, while other tools support both. The reason > is that ping and traceroute are network troubleshooting utilities > that are only used for verifying/testing network connectivity. >=20 > When testing network connectivity you are usually thinking about a > specific protocol. Having seperate versions of the tools removes the > ambiguity for hostnames with both A and AAAA records. If you want > to test v4, use ping, if you want to test v6, use ping6. >=20 > Normal network enabled utilities like telnet or ftp or nc support > both because when using those you usually don't care about the > address family used, you just want to connect. This is a significant > difference from using ping or traceroute where you almost always > want a specific address family, depending on what you are testing. >=20 >=20 > Make sense ? >=20 >=20 > Best regards >=20 > Thomas Steen Rasmussen I believe it does make sense to merge ping6 functionality into ping. You = don't have to stop shipping a ping6 command for those who are used to = it. But there's little difference between ping6 and 'ping -6' in my = opinion. The trickier part is at what point do you transition the = default from 'ping -4' to 'ping -6'. But that doesn't have to happen = right away. Tom From owner-freebsd-net@FreeBSD.ORG Sat Jan 11 13:32:46 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A5A3B4E8 for ; Sat, 11 Jan 2014 13:32:46 +0000 (UTC) Received: from mail.ijs.si (mail.ijs.si [IPv6:2001:1470:ff80::25]) by mx1.freebsd.org (Postfix) with ESMTP id 31AF61335 for ; Sat, 11 Jan 2014 13:32:46 +0000 (UTC) Received: from amavis-proxy-ori.ijs.si (localhost [IPv6:::1]) by mail.ijs.si (Postfix) with ESMTP id 3f1hnm0jHBzGMth for ; Sat, 11 Jan 2014 14:32:44 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ijs.si; h= user-agent:message-id:references:in-reply-to:organization :subject:subject:from:from:date:date:content-transfer-encoding :content-type:content-type:mime-version:received:received :received:received; s=jakla2; t=1389447161; x=1392039162; bh=acT NOS95Nk3uptCBmUhfSmmshKJKn3Y4kCLFJROejB4=; b=F8wsYa2nCA1HlSVmIM3 dVl/z8aCNHoNF0nR+xMYs3ZwqyX0fAKmQUbq/6LANbKiKjAEBw5iP/rfmHictfkP 6GYRWoOApqt71Qw5Ea0j7qZNboziKz4xE7o4NCTGTNqjD6FbP2t6DJel5p2F7uxX Guox2tIMMMos375cl+CFikP0= X-Virus-Scanned: amavisd-new at ijs.si Received: from mail.ijs.si ([IPv6:::1]) by amavis-proxy-ori.ijs.si (mail.ijs.si [IPv6:::1]) (amavisd-new, port 10012) with ESMTP id i16oZY-l1LzM for ; Sat, 11 Jan 2014 14:32:41 +0100 (CET) Received: from mildred.ijs.si (mailbox.ijs.si [IPv6:2001:1470:ff80::143:1]) by mail.ijs.si (Postfix) with ESMTP for ; Sat, 11 Jan 2014 14:32:41 +0100 (CET) Received: from neli.ijs.si (neli.ijs.si [193.2.4.95]) by mildred.ijs.si (Postfix) with ESMTP id 4789F4DF for ; Sat, 11 Jan 2014 14:32:41 +0100 (CET) Received: from sleepy.ijs.si ([2001:1470:ff80:e001::1:1]) by neli.ijs.si with HTTP (HTTP/1.1 POST); Sat, 11 Jan 2014 14:32:41 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Sat, 11 Jan 2014 14:32:41 +0100 From: Mark Martinec To: freebsd-net@freebsd.org Subject: Re: Merge ping+ping6 and traceroue+traceroute6 to single =?UTF-8?Q?utilities=3F?= Organization: J. Stefan Institute In-Reply-To: <52D14140.3090003@gibfest.dk> References: <1063008459.20140111160525@serebryakov.spb.ru> <52D14140.3090003@gibfest.dk> Message-ID: X-Sender: Mark.Martinec+freebsd@ijs.si User-Agent: Roundcube Webmail/0.9.5 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 11 Jan 2014 13:32:46 -0000 > On 11-01-2014 13:05, Lev Serebryakov wrote: >> Is here any project to merge ping/ping6 into ping and >> traceroute/traceroute6 into treaceroute? As IPv6 becomes more common >> these >> days, it is very inconvenient to have these utilities separated. >> 2014-01-11 Thomas Steen Rasmussen wrote: > I hope not, these should remain seperate, allow me to explain: > > There is a good reason these utilities are seperated into v4 and > v6 specific versions, while other tools support both. The reason > is that ping and traceroute are network troubleshooting utilities > that are only used for verifying/testing network connectivity. > > When testing network connectivity you are usually thinking about a > specific protocol. Having seperate versions of the tools removes the > ambiguity for hostnames with both A and AAAA records. If you want > to test v4, use ping, if you want to test v6, use ping6. > > Normal network enabled utilities like telnet or ftp or nc support > both because when using those you usually don't care about the > address family used, you just want to connect. This is a significant > difference from using ping or traceroute where you almost always > want a specific address family, depending on what you are testing. While the argument may be valid from some particular point of view, I'd be very much in favour of having a unified utility. The Windows ping and tracert command line utilities already have options -4 and -6 to force one or the other protocol and I find it very intuitive and convenient. By default they try IPv6 if the target is/has an IPv6 address, and use IPv4 if the target does not have an IPv6 address or if forced by option -4 (or /4 ). A common use of a ping is just to very if a machine is somehow reachable over the network. Often this suffices and it does not matter over which PF it is reachable. The ping6 and traceroute6 could be made just links to a common utility and turn on the -6 option implicitly. For a transition period I could live with the -4 being a default, if that would be a consensus. I'm aware that ICMP and ICMP6 are quite different protocols, but from a user's or sysadmin's perspective one should not need to check first the local and remote protocol family of a host to be pinged, just to be able to see if it is there. Tools like Nagios could benefit too. I sincerely hope that these two utilities could be merged some day, better sooner than later. Mark From owner-freebsd-net@FreeBSD.ORG Sat Jan 11 13:34:52 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B0583585 for ; Sat, 11 Jan 2014 13:34:52 +0000 (UTC) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by mx1.freebsd.org (Postfix) with SMTP id E9B221349 for ; Sat, 11 Jan 2014 13:34:51 +0000 (UTC) Received: (qmail 7129 invoked from network); 11 Jan 2014 13:28:09 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 11 Jan 2014 13:28:09 -0000 Date: Sat, 11 Jan 2014 14:28:09 +0100 (CET) Message-Id: <20140111.142809.74743965.sthaug@nethelp.no> To: lev@FreeBSD.org Subject: Re: Merge ping+ping6 and traceroue+traceroute6 to single utilities? From: sthaug@nethelp.no In-Reply-To: <1063008459.20140111160525@serebryakov.spb.ru> References: <1063008459.20140111160525@serebryakov.spb.ru> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 11 Jan 2014 13:34:52 -0000 > Is here any project to merge ping/ping6 into ping and > traceroute/traceroute6 into treaceroute? As IPv6 becomes more common these > days, it is very inconvenient to have these utilities separated. Yes please, they should absolutely be merged. And then -4 / -6 options could be used (like telnet/ssh) to choose the protocol for names which have both A and AAAA records. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-net@FreeBSD.ORG Sat Jan 11 13:36:46 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7C4E9754 for ; Sat, 11 Jan 2014 13:36:46 +0000 (UTC) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by mx1.freebsd.org (Postfix) with SMTP id C0C011358 for ; Sat, 11 Jan 2014 13:36:45 +0000 (UTC) Received: (qmail 7222 invoked from network); 11 Jan 2014 13:36:44 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 11 Jan 2014 13:36:44 -0000 Date: Sat, 11 Jan 2014 14:36:44 +0100 (CET) Message-Id: <20140111.143644.41639035.sthaug@nethelp.no> To: thomas@gibfest.dk Subject: Re: Merge ping+ping6 and traceroue+traceroute6 to single utilities? From: sthaug@nethelp.no In-Reply-To: <52D14140.3090003@gibfest.dk> References: <1063008459.20140111160525@serebryakov.spb.ru> <52D14140.3090003@gibfest.dk> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: lev@FreeBSD.org, net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 11 Jan 2014 13:36:46 -0000 > Normal network enabled utilities like telnet or ftp or nc support > both because when using those you usually don't care about the > address family used, you just want to connect. This is a significant > difference from using ping or traceroute where you almost always > want a specific address family, depending on what you are testing. I strongly disagree with the "almost always want a specific address family". I normally want to verify that the IP at the other end is alive, or get some idea of how to get there. If I want a specific address family I'm very happy to use -4 / -6 options. I'm used to JunOS where ping/traceroute work for both address families without any more fuss. That's exactly what I also want for FreeBSD. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-net@FreeBSD.ORG Sat Jan 11 13:47:10 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4D8F782D for ; Sat, 11 Jan 2014 13:47:10 +0000 (UTC) Received: from mail.ijs.si (mail.ijs.si [IPv6:2001:1470:ff80::25]) by mx1.freebsd.org (Postfix) with ESMTP id F28E313D6 for ; Sat, 11 Jan 2014 13:47:09 +0000 (UTC) Received: from amavis-proxy-ori.ijs.si (localhost [IPv6:::1]) by mail.ijs.si (Postfix) with ESMTP id 3f1j6P2gH9zGN2K for ; Sat, 11 Jan 2014 14:47:09 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ijs.si; h= user-agent:message-id:references:in-reply-to:organization :subject:subject:from:from:date:date:content-transfer-encoding :content-type:content-type:mime-version:received:received :received:received; s=jakla2; t=1389448026; x=1392040027; bh=ecv isrgeOsfZfwFUyFRX0kYQ4uY2qPRNFtlxIP1ge8I=; b=rb3GMDMtBv2OTLlX7UU jnLoYU7OmmBN7rYojouxRvXkvj2Pr6wdau+3Pej0IbHS6kTHoZ6SJQtA5Pp8Qc9C qCN5d8ovi4gJ+JH88w7Eci2EItoSoCbiWOJHTYamOfE97JXFtflfaARvfjXub83h KAK2SjlEb4nFY86JjP1H4LOE= X-Virus-Scanned: amavisd-new at ijs.si Received: from mail.ijs.si ([IPv6:::1]) by amavis-proxy-ori.ijs.si (mail.ijs.si [IPv6:::1]) (amavisd-new, port 10012) with ESMTP id TUrlV_t2msAU for ; Sat, 11 Jan 2014 14:47:06 +0100 (CET) Received: from mildred.ijs.si (mailbox.ijs.si [IPv6:2001:1470:ff80::143:1]) by mail.ijs.si (Postfix) with ESMTP for ; Sat, 11 Jan 2014 14:47:06 +0100 (CET) Received: from neli.ijs.si (neli.ijs.si [193.2.4.95]) by mildred.ijs.si (Postfix) with ESMTP id 8C486538 for ; Sat, 11 Jan 2014 14:47:06 +0100 (CET) Received: from sleepy.ijs.si ([2001:1470:ff80:e001::1:1]) by neli.ijs.si with HTTP (HTTP/1.1 POST); Sat, 11 Jan 2014 14:47:06 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Sat, 11 Jan 2014 14:47:06 +0100 From: Mark Martinec To: freebsd-net@freebsd.org Subject: Re: Merge ping+ping6 and traceroue+traceroute6 to single =?UTF-8?Q?utilities=3F?= Organization: J. Stefan Institute In-Reply-To: <20140111.143644.41639035.sthaug@nethelp.no> References: <1063008459.20140111160525@serebryakov.spb.ru> <52D14140.3090003@gibfest.dk> <20140111.143644.41639035.sthaug@nethelp.no> Message-ID: X-Sender: Mark.Martinec+freebsd@ijs.si User-Agent: Roundcube Webmail/0.9.5 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 11 Jan 2014 13:47:10 -0000 2014-01-11 14:36, sthaug@nethelp.no wrote: > I'm used to JunOS where ping/traceroute work for both address > families without any more fuss. That's exactly what I also want for > FreeBSD. Indeed, other router manufacturers also have a unified ping and traceroute commands, with options to force one or the other protocol family if necessary. Mark From owner-freebsd-net@FreeBSD.ORG Sat Jan 11 14:13:39 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 38D75E01; Sat, 11 Jan 2014 14:13:39 +0000 (UTC) Received: from mail.tyknet.dk (mail.tyknet.dk [IPv6:2a01:4f8:201:2327:144:76:253:226]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E8BB115D2; Sat, 11 Jan 2014 14:13:38 +0000 (UTC) Received: from [10.10.1.214] (217.71.4.82.static.router4.bolignet.dk [217.71.4.82]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.tyknet.dk (Postfix) with ESMTPSA id 5495A1873E3; Sat, 11 Jan 2014 14:13:28 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail.tyknet.dk 5495A1873E3 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=gibfest.dk; s=default; t=1389449608; bh=vvuSP6Vx3Ye69Z8QM8uRzC35fXG0AHdI091drQvsUf0=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=lmfutYPva1433KQXN0tY+nbMNaLzaM2X2RG8GIow93AsJg4DBE9GDqsg0l53e9WNg ZDkYYCFlOo0qnxlnxmkGnYiu0EHosccJ1FTGp8CNKj8dwCd6d2INXGiQLZxyY6ZQ/4 QnYirvf9cs3QYcfipjIhOJXfcQY0EmhXCSn37S0U= Message-ID: <52D15185.50802@gibfest.dk> Date: Sat, 11 Jan 2014 15:13:25 +0100 From: Thomas Steen Rasmussen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: sthaug@nethelp.no Subject: Re: Merge ping+ping6 and traceroue+traceroute6 to single utilities? References: <1063008459.20140111160525@serebryakov.spb.ru> <52D14140.3090003@gibfest.dk> <20140111.143644.41639035.sthaug@nethelp.no> In-Reply-To: <20140111.143644.41639035.sthaug@nethelp.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: lev@FreeBSD.org, net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 11 Jan 2014 14:13:39 -0000 On 11-01-2014 14:36, sthaug@nethelp.no wrote: >> Normal network enabled utilities like telnet or ftp or nc support >> both because when using those you usually don't care about the >> address family used, you just want to connect. This is a significant >> difference from using ping or traceroute where you almost always >> want a specific address family, depending on what you are testing. > I strongly disagree with the "almost always want a specific address > family". I normally want to verify that the IP at the other end is > alive, or get some idea of how to get there. If I want a specific > address family I'm very happy to use -4 / -6 options. The IP at the other end will, by definition, always be either v4 or v6, so yes, you do want a specific address family - namely the family your IP belongs to. Best regards, Thomas Steen Rasmussen From owner-freebsd-net@FreeBSD.ORG Sat Jan 11 15:24:45 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7F0B26B for ; Sat, 11 Jan 2014 15:24:45 +0000 (UTC) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by mx1.freebsd.org (Postfix) with SMTP id 6F4F819FD for ; Sat, 11 Jan 2014 15:24:43 +0000 (UTC) Received: (qmail 7932 invoked from network); 11 Jan 2014 15:24:41 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 11 Jan 2014 15:24:41 -0000 Date: Sat, 11 Jan 2014 16:24:41 +0100 (CET) Message-Id: <20140111.162441.104033349.sthaug@nethelp.no> To: thomas@gibfest.dk Subject: Re: Merge ping+ping6 and traceroue+traceroute6 to single utilities? From: sthaug@nethelp.no In-Reply-To: <52D15185.50802@gibfest.dk> References: <52D14140.3090003@gibfest.dk> <20140111.143644.41639035.sthaug@nethelp.no> <52D15185.50802@gibfest.dk> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: lev@FreeBSD.org, net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 11 Jan 2014 15:24:45 -0000 > > I strongly disagree with the "almost always want a specific address > > family". I normally want to verify that the IP at the other end is > > alive, or get some idea of how to get there. If I want a specific > > address family I'm very happy to use -4 / -6 options. > > The IP at the other end will, by definition, always be either v4 or v6, > so yes, you do want a specific address family - namely the family your > IP belongs to. If I have an *IP address* (either IPv4 or IPv6), ping/traceroute can select the correct address family automatically, given the format of the address. If I have a *name*, to be used with a DNS lookup: - The name might have only an IPv4 address (A). ping/traceroute can select the correct adress family automatically. - The name might have only an IPv6 address (AAAA). ping/traceroute can select the correct adress family automatically. - The name might have both an IPv4 and an IPv6 address. Only in this case is it necessary to actually specify the address family *if it is important for you*. (There are cases where I don't care, and would be happy to let the system choose the address family. YMMV.) Thus in the three of these four cases ping/traceroute can determine the correct address family automatically. In only one of the cases is it (sometimes) necessary to specify the address family. I definitely want a unified IPv4/IPv6 ping/traceroute. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-net@FreeBSD.ORG Sat Jan 11 16:40:56 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0604FF33 for ; Sat, 11 Jan 2014 16:40:56 +0000 (UTC) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 825311F2C for ; Sat, 11 Jan 2014 16:40:55 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id y1so32227lam.13 for ; Sat, 11 Jan 2014 08:40:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=QLcUKmeIdbYJJekd7dpnSjnwOjlFDUYyIqaoIyl2GcI=; b=CgzzAUrRdRVI/NMRIAG8gEWVmpB/mHa1IU5k1vxzVGHiB9EG9WQD/HuZlw9s4ws76g 05po5Wz5p1Bog40sEZEUp78kqnH+ZGpItb1/gpQWUazj8sb+idmChX5uQje46mVWblQ1 ILDSCk4FBLMd5qjk07YInUSRKFJEtk0YxtfwFHB3T0Eip+ql9S/UvgoMJfxIuykX5SkN xj6tne4q8mCu1iMrWnyW1Zua4y3FvzmGHcFO8FpUE+hycpxPgcSbIvlCgeOS05sH8lNS 2FuyYovxa29jOL5sqI0y+hj3cvnGl9L+a1OPdO1XuHDkk0EE9iwYsI5mPOhbvbzMSqLp DQdA== X-Received: by 10.152.143.101 with SMTP id sd5mr6418639lab.26.1389458453602; Sat, 11 Jan 2014 08:40:53 -0800 (PST) Received: from edge.bac.lab ([91.123.18.167]) by mx.google.com with ESMTPSA id e6sm5759823lbs.3.2014.01.11.08.40.52 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 11 Jan 2014 08:40:53 -0800 (PST) Date: Sat, 11 Jan 2014 20:40:47 +0400 From: mp39590@gmail.com To: freebsd-net@freebsd.org Subject: Re: Merge ping+ping6 and traceroue+traceroute6 to single utilities? Message-ID: <20140111164047.GA97150@edge.bac.lab> References: <1063008459.20140111160525@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1063008459.20140111160525@serebryakov.spb.ru> User-Agent: Mutt/1.5.22 (2013-10-16) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 11 Jan 2014 16:40:56 -0000 On 16:05 11-Jan 2014 Lev Serebryakov wrote: > Hello, Net. > > Is here any project to merge ping/ping6 into ping and > traceroute/traceroute6 into treaceroute? As IPv6 becomes more common these > days, it is very inconvenient to have these utilities separated. > Good evening, Lev. Quoting ping6(8) (and personally, I'm agree with those arguments): There have been many discussions on why we separate ping6 and ping(8). Some people argued that it would be more convenient to uniform the ping command for both IPv4 and IPv6. The followings are an answer to the request. >From a developer's point of view: since the underling raw sockets API is totally different between IPv4 and IPv6, we would end up having two types of code base. There would actually be less benefit to uniform the two commands into a single command from the developer's standpoint. >From an operator's point of view: unlike ordinary network applications like remote login tools, we are usually aware of address family when using network management tools. We do not just want to know the reachability to the host, but want to know the reachability to the host via a particular network protocol such as IPv6. Thus, even if we had a unified ping(8) command for both IPv4 and IPv6, we would usually type a -6 or -4 option (or something like those) to specify the particular address family. This essentially means that we have two different commands. From owner-freebsd-net@FreeBSD.ORG Sat Jan 11 17:01:00 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AB2156BB for ; Sat, 11 Jan 2014 17:01:00 +0000 (UTC) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by mx1.freebsd.org (Postfix) with SMTP id EF74410EB for ; Sat, 11 Jan 2014 17:00:59 +0000 (UTC) Received: (qmail 8528 invoked from network); 11 Jan 2014 17:00:57 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 11 Jan 2014 17:00:57 -0000 Date: Sat, 11 Jan 2014 18:00:57 +0100 (CET) Message-Id: <20140111.180057.78714603.sthaug@nethelp.no> To: mp39590@gmail.com Subject: Re: Merge ping+ping6 and traceroue+traceroute6 to single utilities? From: sthaug@nethelp.no In-Reply-To: <20140111164047.GA97150@edge.bac.lab> References: <1063008459.20140111160525@serebryakov.spb.ru> <20140111164047.GA97150@edge.bac.lab> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 11 Jan 2014 17:01:00 -0000 > >>From an operator's point of view: unlike ordinary network applications like > remote login tools, we are usually aware of address family when using network > management tools. We do not just want to know the reachability to the host, > but want to know the reachability to the host via a particular network protocol > such as IPv6. Thus, even if we had a unified ping(8) command for both IPv4 and > IPv6, we would usually type a -6 or -4 option (or something like those) to > specify the particular address family. This essentially means that we have two > different commands. Disagree. As I showed in my previous message, *only* in the case of a name with both A and AAAA records is this necessary. I use unified ping and traceroute on JunOS daily. It's a blessing not to have to specify the address family. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-net@FreeBSD.ORG Sat Jan 11 17:42:45 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 40C10422 for ; Sat, 11 Jan 2014 17:42:45 +0000 (UTC) Received: from smtp1.bushwire.net (f5.bushwire.net [199.48.133.46]) by mx1.freebsd.org (Postfix) with SMTP id DE11E1389 for ; Sat, 11 Jan 2014 17:42:43 +0000 (UTC) Received: (qmail 6943 invoked by uid 1001); 11 Jan 2014 17:36:01 -0000 Delivered-To: qmda-intercept-freebsd-net@freebsd.org DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=s384; d=romeo.emu.st; b=KkVra6nD6IyReNbBemNDD/cuZSOMI18YEr4TFGgHGB7quManaJXiVWVjIVhrge7c; Comments: DomainKeys? See http://en.wikipedia.org/wiki/DomainKeys DomainKey-Trace-MD: h=13; b=49; l=C18R70D32M64F38T27S76R58?38M17C39C27I50; Comments: QMDA 0.3 Received: (qmail 6935 invoked by uid 1001); 11 Jan 2014 17:36:01 -0000 Date: 11 Jan 2014 17:36:01 +0000 Message-ID: <20140111173601.6934.qmail@f5-external.bushwire.net> From: "Mark Delany" To: freebsd-net@freebsd.org Subject: Re: Merge ping+ping6 and traceroue+traceroute6 to single utilities? References: <1063008459.20140111160525@serebryakov.spb.ru> <20140111164047.GA97150@edge.bac.lab> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20140111164047.GA97150@edge.bac.lab> X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 11 Jan 2014 17:42:45 -0000 On 11Jan14, mp39590@gmail.com allegedly wrote: > From a developer's point of view: since the underling raw sockets API is > totally different between IPv4 and IPv6, we would end up having two types of > code base. > From an operator's point of view: unlike ordinary network applications like > remote login tools, we are usually aware of address family when using network > management tools. We do not just want to know the reachability to the host, Breaking this down by class of users is useful. Another class of users are tool writers. The contortions you have to go thru in a shell script to determine which ping command to run is currently particularly unfriendly. You have to work out whether both ends have one or both classes which is non-trivial. Then you run different commands accordingly and react to all four possible outcomes. Ugly and bug-prone. Furthermore, all existing scripts that have been written over the last couple of decades are gradually breaking and have to be patched as the world evolves to v6. In short, every script writer on the planet is going to have to re-invent a ping4/ping6 wrapper to solve this problem and patch it into all of their existing code. Wouldn't it be nice it those tool writers could just add an option to their existing ping command to encompass both their 4&6 requirements? Or as others have suggested have it "just work" without change? A third way is to provide a "reachability" wrapper around ping4/ping6 but that means training all FBSD users to use a different tool resulting in scripts that don't easily port across platforms. What I'd like semantically in my scripts is: ping [-46..] [-e 1|2|all] Where -e defines minimal reachability for an exit(0) and multiple classes are tested based on -4, -6, -8. So, ping -46 -e2 means both 4 and 6 addresses must respond and ping -46 -e1 means either of 4 or 6 must respond. (It'd also be nice if all the ping writers across platforms agreed on a standardizes output to express results, but that's a whole other problem.) Mark. From owner-freebsd-net@FreeBSD.ORG Sat Jan 11 18:22:46 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 865A9ACA for ; Sat, 11 Jan 2014 18:22:46 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 499241658 for ; Sat, 11 Jan 2014 18:22:46 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:9cb5:5294:4115:885b]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 09B4F4AC2D; Sat, 11 Jan 2014 22:22:44 +0400 (MSK) Date: Sat, 11 Jan 2014 22:22:36 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1218795565.20140111222236@serebryakov.spb.ru> To: Mark Martinec Subject: Re: Merge ping+ping6 and traceroue+traceroute6 to single utilities? In-Reply-To: References: <1063008459.20140111160525@serebryakov.spb.ru> <52D14140.3090003@gibfest.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jan 2014 18:22:46 -0000 Hello, Mark. You wrote 11 =D1=8F=D0=BD=D0=B2=D0=B0=D1=80=D1=8F 2014 =D0=B3., 17:32:41: MM> The ping6 and traceroute6 could be made just links to a common utility MM> and turn on the -6 option implicitly. For a transition period I could MM> live with the -4 being a default, if that would be a consensus. Exactly my point of view. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Sat Jan 11 19:40:23 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EB6BE943; Sat, 11 Jan 2014 19:40:23 +0000 (UTC) Received: from mx1.sbone.de (bird.sbone.de [46.4.1.90]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9B2E51B12; Sat, 11 Jan 2014 19:40:23 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id C049125D3888; Sat, 11 Jan 2014 19:40:14 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id C4C13C22C12; Sat, 11 Jan 2014 19:40:13 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id QNHlZwygwyR9; Sat, 11 Jan 2014 19:40:12 +0000 (UTC) Received: from [IPv6:fde9:577b:c1a9:4410:28f1:d2fb:47da:e988] (unknown [IPv6:fde9:577b:c1a9:4410:28f1:d2fb:47da:e988]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id D1E78C22C0F; Sat, 11 Jan 2014 19:40:11 +0000 (UTC) Subject: Re: Merge ping+ping6 and traceroue+traceroute6 to single utilities? Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Content-Type: text/plain; charset=utf-8 From: "Bjoern A. Zeeb" X-Priority: 3 (Normal) In-Reply-To: <1218795565.20140111222236@serebryakov.spb.ru> Date: Sat, 11 Jan 2014 19:39:48 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <1E09095E-82BB-448E-8EE5-52830F664C3D@lists.zabbadoz.net> References: <1063008459.20140111160525@serebryakov.spb.ru> <52D14140.3090003@gibfest.dk> <1218795565.20140111222236@serebryakov.spb.ru> To: lev@FreeBSD.org X-Mailer: Apple Mail (2.1827) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 11 Jan 2014 19:40:24 -0000 On 11 Jan 2014, at 18:22 , Lev Serebryakov wrote: > Hello, Mark. > You wrote 11 =D1=8F=D0=BD=D0=B2=D0=B0=D1=80=D1=8F 2014 =D0=B3., = 17:32:41: >=20 > MM> The ping6 and traceroute6 could be made just links to a common = utility > MM> and turn on the -6 option implicitly. For a transition period I = could > MM> live with the -4 being a default, if that would be a consensus. > Exactly my point of view. Question =E2=80=94 will you preserve (conflicting) command line options = and if it=E2=80=99s one utility and I use a hostname how will it know = how to interpret them? =E2=80=94=20 Bjoern A. Zeeb ????????? ??? ??????? ??????: '??? ??? ???? ?????? ??????? ?? ?? ??????? ??????? ??? ????? ????? ???? ?????? ?? ????? ????', ????????? ?????????, "??? ????? ?? ?????", ?.??? From owner-freebsd-net@FreeBSD.ORG Sat Jan 11 20:52:12 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7100A5D8 for ; Sat, 11 Jan 2014 20:52:12 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 32CAE13C9 for ; Sat, 11 Jan 2014 20:52:12 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:9cb5:5294:4115:885b]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id CEEEF4AC31; Sun, 12 Jan 2014 00:52:08 +0400 (MSK) Date: Sun, 12 Jan 2014 00:52:01 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1043056268.20140112005201@serebryakov.spb.ru> To: "Bjoern A. Zeeb" Subject: Re: Merge ping+ping6 and traceroue+traceroute6 to single utilities? In-Reply-To: <1E09095E-82BB-448E-8EE5-52830F664C3D@lists.zabbadoz.net> References: <1063008459.20140111160525@serebryakov.spb.ru> <52D14140.3090003@gibfest.dk> <1218795565.20140111222236@serebryakov.spb.ru> <1E09095E-82BB-448E-8EE5-52830F664C3D@lists.zabbadoz.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jan 2014 20:52:12 -0000 Hello, Bjoern. You wrote 11 =D1=8F=D0=BD=D0=B2=D0=B0=D1=80=D1=8F 2014 =D0=B3., 23:39:48: >> >> MM> The ping6 and traceroute6 could be made just links to a common utili= ty >> MM> and turn on the -6 option implicitly. For a transition period I could >> MM> live with the -4 being a default, if that would be a consensus. >> Exactly my point of view. BAZ> Question =E2=80=94 will you preserve (conflicting) command line option= s and if It is good question, indeed. BAZ> it=E2=80=99s one utility and I use a hostname how will it know how to = interpret them? hostname gives ambiguity only if here are both A and AAAA records AND we have both IPv4 and IPv6 addresses configured. In such case we should choose sane default, which could depends on argv[0] :) Also, options parsing could depends on argv[0] too, for backward compatibility. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Sat Jan 11 22:24:34 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D6B06B37; Sat, 11 Jan 2014 22:24:34 +0000 (UTC) Received: from mail-oa0-x22e.google.com (mail-oa0-x22e.google.com [IPv6:2607:f8b0:4003:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 902B41A4A; Sat, 11 Jan 2014 22:24:34 +0000 (UTC) Received: by mail-oa0-f46.google.com with SMTP id l6so6534595oag.19 for ; Sat, 11 Jan 2014 14:24:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=b7yWD4YZeUu51KK44sg1Gzf9pSOqQlcRmcYyv1pwbYw=; b=cefleVrHPirW8b0l8lyipqe716Cs691ggsYdlNWacK3vsiqfAL5LMdJmcpxWGmeGST WIpEUYBQQFJPlNZvVI52tspa5oaDlBoLZTlvbVILFqyiq2OLCPmrfqxzVRp6Y2+tcPcW prH8kRObg2CYuxdLWEKAthwJJKSV0PnLou9Cw4zDL+NsJV0PMgNmBA4SDvMQ423Pf7MX E+bJRWRcyUETHc0VBzHr58dWd5OeYRnWAVF0QYPa+Lk3WTrKBMHQgXXRjpVFL8v/7A1d BMJtrDZn230fFoOmZ5maseLh42LGSuqF7mmM7bQJTCpDId94Uue00t66p3iHSH3Kd9a1 MDJg== MIME-Version: 1.0 X-Received: by 10.182.66.164 with SMTP id g4mr14382826obt.47.1389479073810; Sat, 11 Jan 2014 14:24:33 -0800 (PST) Received: by 10.76.20.82 with HTTP; Sat, 11 Jan 2014 14:24:33 -0800 (PST) Date: Sun, 12 Jan 2014 00:24:33 +0200 Message-ID: Subject: Re: 10.0-RC1, armv6: "pfctl -s state" crashes on BeagleBone Black due to unaligned access From: Guy Yur To: freebsd-net@freebsd.org, freebsd-arm@freebsd.org Content-Type: multipart/mixed; boundary=089e0160c35e9e329d04efb94ed2 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 11 Jan 2014 22:24:34 -0000 --089e0160c35e9e329d04efb94ed2 Content-Type: text/plain; charset=UTF-8 Hi, New patch that adds new aligned state structs and new ioctls. A trade-off of allowing correct alignment and improved speed for architectures that require alignment at the cost of extra maintenance when the state structs need to be extended. I duplicated the structs pfsync_state_scrub, pfsync_state_peer, pfsync_state_key and pfsync_state as non __packed structures. (pfsync_state_key is not marked as __packed, should it be?) pfsync_state_export also duplicated for the new struct. In the new state struct I reordered creatorid before the packets array to keep alignment on 8 bytes. packets and bytes converted to u_int64_t instead of array of u_int32_t (they are u_int64_t in the internal pf_state). sizeof(struct pf_addr) = 16; 16 % 4 = 0 sizeof(struct pfioc_state2_scrub) = 8; 8 % 4 = 0 sizeof(struct pfioc_state2_peer) = 28; 28 % 4 = 0 sizeof(struct pfioc_state2_key) = 36; 36 % 4 = 0 sizeof(struct pfioc_state2) = 232; 232 % 8 = 0 offsetof(struct pfioc_state2, src) = 96; 96 % 4 = 0 offsetof(struct pfioc_state2, dst) = 124; 124 % 4 = 0 offsetof(struct pfioc_state2, rt_addr) = 152; 152 % 4 = 0 offsetof(struct pfioc_state2, rule) = 168; 168 % 4 = 0 offsetof(struct pfioc_state2, packets) = 192; 192 % 8 = 0 The export for the new struct is done in host byte order which is used by the internal pf_state structure (except for pf_addr, id and creatorid which are kept in network order). I didn't bother creating a new version of DIOCADDSTATE since it is only used for pfsync and it receives only one pfioc_state / pfsync_state. Tested both of the new ioctls on the BeagleBone Black by modifying pfctl to also issue the single state ioctl with the (id,creatorid) of the last entry found in the print loop. I am not sure about the new structs and ioctls naming and there might be style bugs. Also attached a patch to constify the print functions in pfctl if there is interest in that. Needs to be applied after the new structs patch. P.S. Are alignment traps disabled on the Raspberry Pi? I wasn't able to cause a user space crash on the Pi with unaligned access. Regards, Guy --089e0160c35e9e329d04efb94ed2 Content-Type: application/octet-stream; name="pf-pfioc_state2.patch" Content-Disposition: attachment; filename="pf-pfioc_state2.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hqbfbiu50 SW5kZXg6IHN5cy9uZXQvcGZ2YXIuaAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvbmV0L3BmdmFyLmgJKHJl dmlzaW9uIDI2MDQ5MikKKysrIHN5cy9uZXQvcGZ2YXIuaAkod29ya2luZyBjb3B5KQpAQCAtOTQz LDYgKzk0MywyMyBAQCBleHRlcm4gcGZsb2dfcGFja2V0X3QJCSpwZmxvZ19wYWNrZXRfcHRyOwog CX0JCQkJCQkJCVwKIH0gd2hpbGUgKDApCiAKKyNkZWZpbmUgcGZfc3RhdGVfcGVlcl9odG9oKHMs ZCkgZG8gewkJXAorCShkKS0+c2VxbG8gPSAocyktPnNlcWxvOwkJXAorCShkKS0+c2VxaGkgPSAo cyktPnNlcWhpOwkJXAorCShkKS0+c2VxZGlmZiA9IChzKS0+c2VxZGlmZjsJCVwKKwkoZCktPm1h eF93aW4gPSAocyktPm1heF93aW47CQlcCisJKGQpLT5tc3MgPSAocyktPm1zczsJCQlcCisJKGQp LT5zdGF0ZSA9IChzKS0+c3RhdGU7CQlcCisJKGQpLT53c2NhbGUgPSAocyktPndzY2FsZTsJCVwK KwlpZiAoKHMpLT5zY3J1YikgewkJCQkJCVwKKwkJKGQpLT5zY3J1Yi5wZnNzX2ZsYWdzID0gCQkJ CVwKKwkJICAgIChzKS0+c2NydWItPnBmc3NfZmxhZ3MgJiBQRlNTX1RJTUVTVEFNUDsJCVwKKwkJ KGQpLT5zY3J1Yi5wZnNzX3R0bCA9IChzKS0+c2NydWItPnBmc3NfdHRsOwkJXAorCQkoZCktPnNj cnViLnBmc3NfdHNfbW9kID0gKHMpLT5zY3J1Yi0+cGZzc190c19tb2Q7CVwKKwkJKGQpLT5zY3J1 Yi5zY3J1Yl9mbGFnID0gUEZTWU5DX1NDUlVCX0ZMQUdfVkFMSUQ7CVwKKwl9CQkJCQkJCQlcCit9 IHdoaWxlICgwKQorCiAjZGVmaW5lIHBmX3N0YXRlX2NvdW50ZXJfaHRvbihzLGQpIGRvIHsJCQkJ XAogCWRbMF0gPSBodG9ubCgocz4+MzIpJjB4ZmZmZmZmZmYpOwkJCVwKIAlkWzFdID0gaHRvbmwo cyYweGZmZmZmZmZmKTsJCQkJXApAQCAtMTQ0MCw2ICsxNDU3LDU1IEBAIHN0cnVjdCBwZmlvY19z dGF0ZSB7CiAJc3RydWN0IHBmc3luY19zdGF0ZQlzdGF0ZTsKIH07CiAKK3N0cnVjdCBwZmlvY19z dGF0ZTJfc2NydWIgeworCXVfaW50MTZfdAlwZnNzX2ZsYWdzOworCXVfaW50OF90CXBmc3NfdHRs OwkvKiBzdGFzaGVkIFRUTAkJKi8KKyNkZWZpbmUgUEZJT0NfU0NSVUJfRkxBR19WQUxJRAkJUEZT WU5DX1NDUlVCX0ZMQUdfVkFMSUQKKwl1X2ludDhfdAlzY3J1Yl9mbGFnOworCXVfaW50MzJfdAlw ZnNzX3RzX21vZDsJLyogdGltZXN0YW1wIG1vZHVsYXRpb24JKi8KK307CisKK3N0cnVjdCBwZmlv Y19zdGF0ZTJfcGVlciB7CisJc3RydWN0IHBmaW9jX3N0YXRlMl9zY3J1YiBzY3J1YjsJLyogc3Rh dGUgaXMgc2NydWJiZWQJKi8KKwl1X2ludDMyX3QJc2VxbG87CQkvKiBNYXggc2VxdWVuY2UgbnVt YmVyIHNlbnQJKi8KKwl1X2ludDMyX3QJc2VxaGk7CQkvKiBNYXggdGhlIG90aGVyIGVuZCBBQ0tk ICsgd2luCSovCisJdV9pbnQzMl90CXNlcWRpZmY7CS8qIFNlcXVlbmNlIG51bWJlciBtb2R1bGF0 b3IJKi8KKwl1X2ludDE2X3QJbWF4X3dpbjsJLyogbGFyZ2VzdCB3aW5kb3cgKHByZSBzY2FsaW5n KQkqLworCXVfaW50MTZfdAltc3M7CQkvKiBNYXhpbXVtIHNlZ21lbnQgc2l6ZSBvcHRpb24JKi8K Kwl1X2ludDhfdAlzdGF0ZTsJCS8qIGFjdGl2ZSBzdGF0ZSBsZXZlbAkJKi8KKwl1X2ludDhfdAl3 c2NhbGU7CQkvKiB3aW5kb3cgc2NhbGluZyBmYWN0b3IJKi8KK307CisKK3N0cnVjdCBwZmlvY19z dGF0ZTJfa2V5IHsKKwlzdHJ1Y3QgcGZfYWRkcgkgYWRkclsyXTsKKwl1X2ludDE2X3QJIHBvcnRb Ml07Cit9OworCitzdHJ1Y3QgcGZpb2Nfc3RhdGUyIHsKKwl1X2ludDY0X3QJIGlkOworCWNoYXIJ CSBpZm5hbWVbSUZOQU1TSVpdOworCXN0cnVjdCBwZmlvY19zdGF0ZTJfa2V5CWtleVsyXTsKKwlz dHJ1Y3QgcGZpb2Nfc3RhdGUyX3BlZXIgc3JjOworCXN0cnVjdCBwZmlvY19zdGF0ZTJfcGVlciBk c3Q7CisJc3RydWN0IHBmX2FkZHIJIHJ0X2FkZHI7CisJdV9pbnQzMl90CSBydWxlOworCXVfaW50 MzJfdAkgYW5jaG9yOworCXVfaW50MzJfdAkgbmF0X3J1bGU7CisJdV9pbnQzMl90CSBjcmVhdGlv bjsKKwl1X2ludDMyX3QJIGV4cGlyZTsKKwl1X2ludDMyX3QJIGNyZWF0b3JpZDsKKwl1X2ludDY0 X3QJIHBhY2tldHNbMl07CisJdV9pbnQ2NF90CSBieXRlc1syXTsKKwlzYV9mYW1pbHlfdAkgYWY7 CisJdV9pbnQ4X3QJIHByb3RvOworCXVfaW50OF90CSBkaXJlY3Rpb247CisJdV9pbnQ4X3QJIGxv ZzsKKwl1X2ludDhfdAkgc3RhdGVfZmxhZ3M7CisJdV9pbnQ4X3QJIHRpbWVvdXQ7CisJdV9pbnQ4 X3QJIHN5bmNfZmxhZ3M7CisJdV9pbnQ4X3QJIHVwZGF0ZXM7Cit9OworCiBzdHJ1Y3QgcGZpb2Nf c3JjX25vZGVfa2lsbCB7CiAJc2FfZmFtaWx5X3QgcHNua19hZjsKIAlzdHJ1Y3QgcGZfcnVsZV9h ZGRyIHBzbmtfc3JjOwpAQCAtMTQ2OCw2ICsxNTM0LDE0IEBAIHN0cnVjdCBwZmlvY19zdGF0ZXMg ewogI2RlZmluZSBwc19zdGF0ZXMJcHNfdS5wc3Vfc3RhdGVzCiB9OwogCitzdHJ1Y3QgcGZpb2Nf c3RhdGVzMiB7CisJaW50CXBzX2xlbjsKKwl1bmlvbiB7CisJCWNhZGRyX3QJCQkgcHN1X2J1ZjsK KwkJc3RydWN0IHBmaW9jX3N0YXRlMgkqcHN1X3N0YXRlczsKKwl9IHBzX3U7Cit9OworCiBzdHJ1 Y3QgcGZpb2Nfc3JjX25vZGVzIHsKIAlpbnQJcHNuX2xlbjsKIAl1bmlvbiB7CkBAIC0xNjQyLDYg KzE3MTYsOCBAQCBzdHJ1Y3QgcGZfaWZzcGVlZCB7CiAJdV9pbnQzMl90CQliYXVkcmF0ZTsKIH07 CiAjZGVmaW5lCURJT0NHSUZTUEVFRAlfSU9XUignRCcsIDkyLCBzdHJ1Y3QgcGZfaWZzcGVlZCkK KyNkZWZpbmUgRElPQ0dFVFNUQVRFMglfSU9XUignRCcsIDkzLCBzdHJ1Y3QgcGZpb2Nfc3RhdGUy KQorI2RlZmluZSBESU9DR0VUU1RBVEVTMglfSU9XUignRCcsIDk0LCBzdHJ1Y3QgcGZpb2Nfc3Rh dGVzMikKIAogI2lmZGVmIF9LRVJORUwKIHN0cnVjdCBwZl9zcmNoYXNoIHsKSW5kZXg6IHN5cy9u ZXRwZmlsL3BmL3BmX2lvY3RsLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL25ldHBmaWwvcGYvcGZfaW9j dGwuYwkocmV2aXNpb24gMjYwNDkyKQorKysgc3lzL25ldHBmaWwvcGYvcGZfaW9jdGwuYwkod29y a2luZyBjb3B5KQpAQCAtMTA4LDYgKzEwOCw4IEBAIHN0YXRpYyBpbnQJCSBwZl9jb21taXRfcnVs ZXModV9pbnQzMl90LCBpbnQsIGNoYXIKIHN0YXRpYyBpbnQJCSBwZl9hZGRyX3NldHVwKHN0cnVj dCBwZl9ydWxlc2V0ICosCiAJCQkgICAgc3RydWN0IHBmX2FkZHJfd3JhcCAqLCBzYV9mYW1pbHlf dCk7CiBzdGF0aWMgdm9pZAkJIHBmX2FkZHJfY29weW91dChzdHJ1Y3QgcGZfYWRkcl93cmFwICop Oworc3RhdGljIHZvaWQJCSBwZmlvY19zdGF0ZTJfZXhwb3J0KHN0cnVjdCBwZmlvY19zdGF0ZTIg KnNwLAorCQkJICAgIHN0cnVjdCBwZl9zdGF0ZSAqc3QpOwogCiBWTkVUX0RFRklORShzdHJ1Y3Qg cGZfcnVsZSwJcGZfZGVmYXVsdF9ydWxlKTsKIApAQCAtMTAwMyw2ICsxMDA1LDggQEAgcGZpb2N0 bChzdHJ1Y3QgY2RldiAqZGV2LCB1X2xvbmcgY21kLCBjYWRkcl90IGFkZHIKIAkJY2FzZSBESU9D R0lGU1BFRUQ6CiAJCWNhc2UgRElPQ1NFVElGRkxBRzoKIAkJY2FzZSBESU9DQ0xSSUZGTEFHOgor CQljYXNlIERJT0NHRVRTVEFURTI6CisJCWNhc2UgRElPQ0dFVFNUQVRFUzI6CiAJCQlicmVhazsK IAkJY2FzZSBESU9DUkNMUlRBQkxFUzoKIAkJY2FzZSBESU9DUkFERFRBQkxFUzoKQEAgLTEwNDEs NiArMTA0NSw4IEBAIHBmaW9jdGwoc3RydWN0IGNkZXYgKmRldiwgdV9sb25nIGNtZCwgY2FkZHJf dCBhZGRyCiAJCWNhc2UgRElPQ0dFVFNSQ05PREVTOgogCQljYXNlIERJT0NJR0VUSUZBQ0VTOgog CQljYXNlIERJT0NHSUZTUEVFRDoKKwkJY2FzZSBESU9DR0VUU1RBVEUyOgorCQljYXNlIERJT0NH RVRTVEFURVMyOgogCQkJYnJlYWs7CiAJCWNhc2UgRElPQ1JDTFJUQUJMRVM6CiAJCWNhc2UgRElP Q1JBRERUQUJMRVM6CkBAIC0xNzU4LDYgKzE3NjQsNjggQEAgRElPQ0dFVFNUQVRFU19mdWxsOgog CQlicmVhazsKIAl9CiAKKwljYXNlIERJT0NHRVRTVEFURTI6IHsKKwkJc3RydWN0IHBmaW9jX3N0 YXRlMgkqcHMgPSAoc3RydWN0IHBmaW9jX3N0YXRlMiAqKWFkZHI7CisJCXN0cnVjdCBwZl9zdGF0 ZQkJKnM7CisKKwkJcyA9IHBmX2ZpbmRfc3RhdGVfYnlpZChwcy0+aWQsIHBzLT5jcmVhdG9yaWQp OworCQlpZiAocyA9PSBOVUxMKSB7CisJCQllcnJvciA9IEVOT0VOVDsKKwkJCWJyZWFrOworCQl9 CisKKwkJcGZpb2Nfc3RhdGUyX2V4cG9ydChwcywgcyk7CisJCVBGX1NUQVRFX1VOTE9DSyhzKTsK KwkJYnJlYWs7CisJfQorCisJY2FzZSBESU9DR0VUU1RBVEVTMjogeworCQlzdHJ1Y3QgcGZpb2Nf c3RhdGVzMgkqcHMgPSAoc3RydWN0IHBmaW9jX3N0YXRlczIgKilhZGRyOworCQlzdHJ1Y3QgcGZf c3RhdGUJCSpzOworCQlzdHJ1Y3QgcGZpb2Nfc3RhdGUyCSpwc3RvcmUsICpwOworCQlpbnQgaSwg bnI7CisKKwkJaWYgKHBzLT5wc19sZW4gPT0gMCkgeworCQkJbnIgPSB1bWFfem9uZV9nZXRfY3Vy KFZfcGZfc3RhdGVfeik7CisJCQlwcy0+cHNfbGVuID0gc2l6ZW9mKHN0cnVjdCBwZmlvY19zdGF0 ZTIpICogbnI7CisJCQlicmVhazsKKwkJfQorCisJCXAgPSBwc3RvcmUgPSBtYWxsb2MocHMtPnBz X2xlbiwgTV9URU1QLCBNX1dBSVRPSyk7CisJCW5yID0gMDsKKworCQlmb3IgKGkgPSAwOyBpIDw9 IFZfcGZfaGFzaG1hc2s7IGkrKykgeworCQkJc3RydWN0IHBmX2lkaGFzaCAqaWggPSAmVl9wZl9p ZGhhc2hbaV07CisKKwkJCVBGX0hBU0hST1dfTE9DSyhpaCk7CisJCQlMSVNUX0ZPUkVBQ0gocywg JmloLT5zdGF0ZXMsIGVudHJ5KSB7CisKKwkJCQlpZiAocy0+dGltZW91dCA9PSBQRlRNX1VOTElO S0VEKQorCQkJCQljb250aW51ZTsKKworCQkJCWlmICgobnIrMSkgKiBzaXplb2YoKnApID4gcHMt PnBzX2xlbikgeworCQkJCQlQRl9IQVNIUk9XX1VOTE9DSyhpaCk7CisJCQkJCWdvdG8gRElPQ0dF VFNUQVRFUzJfZnVsbDsKKwkJCQl9CisJCQkJcGZpb2Nfc3RhdGUyX2V4cG9ydChwLCBzKTsKKwkJ CQlwKys7CisJCQkJbnIrKzsKKwkJCX0KKwkJCVBGX0hBU0hST1dfVU5MT0NLKGloKTsKKwkJfQor RElPQ0dFVFNUQVRFUzJfZnVsbDoKKwkJZXJyb3IgPSBjb3B5b3V0KHBzdG9yZSwgcHMtPnBzX3N0 YXRlcywKKwkJICAgIHNpemVvZihzdHJ1Y3QgcGZpb2Nfc3RhdGUyKSAqIG5yKTsKKwkJaWYgKGVy cm9yKSB7CisJCQlmcmVlKHBzdG9yZSwgTV9URU1QKTsKKwkJCWJyZWFrOworCQl9CisJCXBzLT5w c19sZW4gPSBzaXplb2Yoc3RydWN0IHBmaW9jX3N0YXRlMikgKiBucjsKKwkJZnJlZShwc3RvcmUs IE1fVEVNUCk7CisKKwkJYnJlYWs7CisJfQorCiAJY2FzZSBESU9DR0VUU1RBVFVTOiB7CiAJCXN0 cnVjdCBwZl9zdGF0dXMgKnMgPSAoc3RydWN0IHBmX3N0YXR1cyAqKWFkZHI7CiAJCVBGX1JVTEVT X1JMT0NLKCk7CkBAIC0zMzA4LDYgKzMzNzYsNjYgQEAgcGZzeW5jX3N0YXRlX2V4cG9ydChzdHJ1 Y3QgcGZzeW5jX3N0YXRlICpzcCwgc3RydWMKIH0KIAogc3RhdGljIHZvaWQKK3BmaW9jX3N0YXRl Ml9leHBvcnQoc3RydWN0IHBmaW9jX3N0YXRlMiAqc3AsIHN0cnVjdCBwZl9zdGF0ZSAqc3QpCit7 CisJYnplcm8oc3AsIHNpemVvZihzdHJ1Y3QgcGZpb2Nfc3RhdGUyKSk7CisKKwkvKiBjb3B5IGZy b20gc3RhdGUga2V5ICovCisJc3AtPmtleVtQRl9TS19XSVJFXS5hZGRyWzBdID0gc3QtPmtleVtQ Rl9TS19XSVJFXS0+YWRkclswXTsKKwlzcC0+a2V5W1BGX1NLX1dJUkVdLmFkZHJbMV0gPSBzdC0+ a2V5W1BGX1NLX1dJUkVdLT5hZGRyWzFdOworCXNwLT5rZXlbUEZfU0tfV0lSRV0ucG9ydFswXSA9 IHN0LT5rZXlbUEZfU0tfV0lSRV0tPnBvcnRbMF07CisJc3AtPmtleVtQRl9TS19XSVJFXS5wb3J0 WzFdID0gc3QtPmtleVtQRl9TS19XSVJFXS0+cG9ydFsxXTsKKwlzcC0+a2V5W1BGX1NLX1NUQUNL XS5hZGRyWzBdID0gc3QtPmtleVtQRl9TS19TVEFDS10tPmFkZHJbMF07CisJc3AtPmtleVtQRl9T S19TVEFDS10uYWRkclsxXSA9IHN0LT5rZXlbUEZfU0tfU1RBQ0tdLT5hZGRyWzFdOworCXNwLT5r ZXlbUEZfU0tfU1RBQ0tdLnBvcnRbMF0gPSBzdC0+a2V5W1BGX1NLX1NUQUNLXS0+cG9ydFswXTsK KwlzcC0+a2V5W1BGX1NLX1NUQUNLXS5wb3J0WzFdID0gc3QtPmtleVtQRl9TS19TVEFDS10tPnBv cnRbMV07CisJc3AtPnByb3RvID0gc3QtPmtleVtQRl9TS19XSVJFXS0+cHJvdG87CisJc3AtPmFm ID0gc3QtPmtleVtQRl9TS19XSVJFXS0+YWY7CisKKwkvKiBjb3B5IGZyb20gc3RhdGUgKi8KKwlz dHJsY3B5KHNwLT5pZm5hbWUsIHN0LT5raWYtPnBmaWtfbmFtZSwgc2l6ZW9mKHNwLT5pZm5hbWUp KTsKKwliY29weSgmc3QtPnJ0X2FkZHIsICZzcC0+cnRfYWRkciwgc2l6ZW9mKHNwLT5ydF9hZGRy KSk7CisJc3AtPmNyZWF0aW9uID0gdGltZV91cHRpbWUgLSBzdC0+Y3JlYXRpb247CisJc3AtPmV4 cGlyZSA9IHBmX3N0YXRlX2V4cGlyZXMoc3QpOworCWlmIChzcC0+ZXhwaXJlIDw9IHRpbWVfdXB0 aW1lKQorCQlzcC0+ZXhwaXJlID0gMDsKKwllbHNlCisJCXNwLT5leHBpcmUgPSBzcC0+ZXhwaXJl IC0gdGltZV91cHRpbWU7CisKKwlzcC0+ZGlyZWN0aW9uID0gc3QtPmRpcmVjdGlvbjsKKwlzcC0+ bG9nID0gc3QtPmxvZzsKKwlzcC0+dGltZW91dCA9IHN0LT50aW1lb3V0OworCXNwLT5zdGF0ZV9m bGFncyA9IHN0LT5zdGF0ZV9mbGFnczsKKwlpZiAoc3QtPnNyY19ub2RlKQorCQlzcC0+c3luY19m bGFncyB8PSBQRlNZTkNfRkxBR19TUkNOT0RFOworCWlmIChzdC0+bmF0X3NyY19ub2RlKQorCQlz cC0+c3luY19mbGFncyB8PSBQRlNZTkNfRkxBR19OQVRTUkNOT0RFOworCisJc3AtPmlkID0gc3Qt PmlkOworCXNwLT5jcmVhdG9yaWQgPSBzdC0+Y3JlYXRvcmlkOworCXBmX3N0YXRlX3BlZXJfaHRv aCgmc3QtPnNyYywgJnNwLT5zcmMpOworCXBmX3N0YXRlX3BlZXJfaHRvaCgmc3QtPmRzdCwgJnNw LT5kc3QpOworCisJaWYgKHN0LT5ydWxlLnB0ciA9PSBOVUxMKQorCQlzcC0+cnVsZSA9IC0xOwor CWVsc2UKKwkJc3AtPnJ1bGUgPSBzdC0+cnVsZS5wdHItPm5yOworCWlmIChzdC0+YW5jaG9yLnB0 ciA9PSBOVUxMKQorCQlzcC0+YW5jaG9yID0gLTE7CisJZWxzZQorCQlzcC0+YW5jaG9yID0gc3Qt PmFuY2hvci5wdHItPm5yOworCWlmIChzdC0+bmF0X3J1bGUucHRyID09IE5VTEwpCisJCXNwLT5u YXRfcnVsZSA9IC0xOworCWVsc2UKKwkJc3AtPm5hdF9ydWxlID0gc3QtPm5hdF9ydWxlLnB0ci0+ bnI7CisKKwlzcC0+cGFja2V0c1swXSA9IHN0LT5wYWNrZXRzWzBdOworCXNwLT5wYWNrZXRzWzFd ID0gc3QtPnBhY2tldHNbMV07CisJc3AtPmJ5dGVzWzBdID0gc3QtPmJ5dGVzWzBdOworCXNwLT5i eXRlc1sxXSA9IHN0LT5ieXRlc1sxXTsKK30KKworc3RhdGljIHZvaWQKIHBmX3RibGFkZHJfY29w eW91dChzdHJ1Y3QgcGZfYWRkcl93cmFwICphdykKIHsKIAlzdHJ1Y3QgcGZyX2t0YWJsZSAqa3Q7 CkluZGV4OiBzYmluL3BmY3RsL3BmX3ByaW50X3N0YXRlLmMKPT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc2Jpbi9w ZmN0bC9wZl9wcmludF9zdGF0ZS5jCShyZXZpc2lvbiAyNjA0OTIpCisrKyBzYmluL3BmY3RsL3Bm X3ByaW50X3N0YXRlLmMJKHdvcmtpbmcgY29weSkKQEAgLTE5NCwyMSArMTk0LDIwIEBAIHByaW50 X2hvc3Qoc3RydWN0IHBmX2FkZHIgKmFkZHIsIHVfaW50MTZfdCBwb3J0LCBzCiB9CiAKIHZvaWQK LXByaW50X3NlcShzdHJ1Y3QgcGZzeW5jX3N0YXRlX3BlZXIgKnApCitwcmludF9zZXEoc3RydWN0 IHBmaW9jX3N0YXRlMl9wZWVyICpwKQogewogCWlmIChwLT5zZXFkaWZmKQotCQlwcmludGYoIlsl dSArICV1XSgrJXUpIiwgbnRvaGwocC0+c2VxbG8pLAotCQkgICAgbnRvaGwocC0+c2VxaGkpIC0g bnRvaGwocC0+c2VxbG8pLCBudG9obChwLT5zZXFkaWZmKSk7CisJCXByaW50ZigiWyV1ICsgJXVd KCsldSkiLCBwLT5zZXFsbywgcC0+c2VxaGkgLSBwLT5zZXFsbywKKwkJICAgIHAtPnNlcWRpZmYp OwogCWVsc2UKLQkJcHJpbnRmKCJbJXUgKyAldV0iLCBudG9obChwLT5zZXFsbyksCi0JCSAgICBu dG9obChwLT5zZXFoaSkgLSBudG9obChwLT5zZXFsbykpOworCQlwcmludGYoIlsldSArICV1XSIs IHAtPnNlcWxvLCBwLT5zZXFoaSAtIHAtPnNlcWxvKTsKIH0KIAogdm9pZAotcHJpbnRfc3RhdGUo c3RydWN0IHBmc3luY19zdGF0ZSAqcywgaW50IG9wdHMpCitwcmludF9zdGF0ZShzdHJ1Y3QgcGZp b2Nfc3RhdGUyICpzLCBpbnQgb3B0cykKIHsKLQlzdHJ1Y3QgcGZzeW5jX3N0YXRlX3BlZXIgKnNy YywgKmRzdDsKLQlzdHJ1Y3QgcGZzeW5jX3N0YXRlX2tleSAqc2ssICpuazsKKwlzdHJ1Y3QgcGZp b2Nfc3RhdGUyX3BlZXIgKnNyYywgKmRzdDsKKwlzdHJ1Y3QgcGZpb2Nfc3RhdGUyX2tleSAqc2ss ICpuazsKIAlzdHJ1Y3QgcHJvdG9lbnQgKnA7CiAJaW50IG1pbiwgc2VjOwogCkBAIC0yOTYsMTAg KzI5NSw4IEBAIHZvaWQKIAl9CiAKIAlpZiAob3B0cyAmIFBGX09QVF9WRVJCT1NFKSB7Ci0JCXVf aW50NjRfdCBwYWNrZXRzWzJdOwotCQl1X2ludDY0X3QgYnl0ZXNbMl07Ci0JCXVfaW50MzJfdCBj cmVhdGlvbiA9IG50b2hsKHMtPmNyZWF0aW9uKTsKLQkJdV9pbnQzMl90IGV4cGlyZSA9IG50b2hs KHMtPmV4cGlyZSk7CisJCXVfaW50MzJfdCBjcmVhdGlvbiA9IHMtPmNyZWF0aW9uOworCQl1X2lu dDMyX3QgZXhwaXJlID0gcy0+ZXhwaXJlOwogCiAJCXNlYyA9IGNyZWF0aW9uICUgNjA7CiAJCWNy ZWF0aW9uIC89IDYwOwpAQCAtMzEyLDE5ICszMDksMTMgQEAgdm9pZAogCQlleHBpcmUgLz0gNjA7 CiAJCXByaW50ZigiLCBleHBpcmVzIGluICUuMnU6JS4ydTolLjJ1IiwgZXhwaXJlLCBtaW4sIHNl Yyk7CiAKLQkJYmNvcHkocy0+cGFja2V0c1swXSwgJnBhY2tldHNbMF0sIHNpemVvZih1X2ludDY0 X3QpKTsKLQkJYmNvcHkocy0+cGFja2V0c1sxXSwgJnBhY2tldHNbMV0sIHNpemVvZih1X2ludDY0 X3QpKTsKLQkJYmNvcHkocy0+Ynl0ZXNbMF0sICZieXRlc1swXSwgc2l6ZW9mKHVfaW50NjRfdCkp OwotCQliY29weShzLT5ieXRlc1sxXSwgJmJ5dGVzWzFdLCBzaXplb2YodV9pbnQ2NF90KSk7CiAJ CXByaW50ZigiLCAlanU6JWp1IHBrdHMsICVqdTolanUgYnl0ZXMiLAotCQkgICAgKHVpbnRtYXhf dCApYmU2NHRvaChwYWNrZXRzWzBdKSwKLQkJICAgICh1aW50bWF4X3QgKWJlNjR0b2gocGFja2V0 c1sxXSksCi0JCSAgICAodWludG1heF90ICliZTY0dG9oKGJ5dGVzWzBdKSwKLQkJICAgICh1aW50 bWF4X3QgKWJlNjR0b2goYnl0ZXNbMV0pKTsKLQkJaWYgKG50b2hsKHMtPmFuY2hvcikgIT0gLTEp Ci0JCQlwcmludGYoIiwgYW5jaG9yICV1IiwgbnRvaGwocy0+YW5jaG9yKSk7Ci0JCWlmIChudG9o bChzLT5ydWxlKSAhPSAtMSkKLQkJCXByaW50ZigiLCBydWxlICV1IiwgbnRvaGwocy0+cnVsZSkp OworCQkgICAgKHVpbnRtYXhfdClzLT5wYWNrZXRzWzBdLCAodWludG1heF90KXMtPnBhY2tldHNb MV0sCisJCSAgICAodWludG1heF90KXMtPmJ5dGVzWzBdLCAodWludG1heF90KXMtPmJ5dGVzWzFd KTsKKwkJaWYgKHMtPmFuY2hvciAhPSAtMSkKKwkJCXByaW50ZigiLCBhbmNob3IgJXUiLCBzLT5h bmNob3IpOworCQlpZiAocy0+cnVsZSAhPSAtMSkKKwkJCXByaW50ZigiLCBydWxlICV1Iiwgcy0+ cnVsZSk7CiAJCWlmIChzLT5zdGF0ZV9mbGFncyAmIFBGU1RBVEVfU0xPUFBZKQogCQkJcHJpbnRm KCIsIHNsb3BweSIpOwogCQlpZiAocy0+c3luY19mbGFncyAmIFBGU1lOQ19GTEFHX1NSQ05PREUp CkBAIC0zMzQsMTEgKzMyNSw4IEBAIHZvaWQKIAkJcHJpbnRmKCJcbiIpOwogCX0KIAlpZiAob3B0 cyAmIFBGX09QVF9WRVJCT1NFMikgewotCQl1X2ludDY0X3QgaWQ7Ci0KLQkJYmNvcHkoJnMtPmlk LCAmaWQsIHNpemVvZih1X2ludDY0X3QpKTsKIAkJcHJpbnRmKCIgICBpZDogJTAxNmp4IGNyZWF0 b3JpZDogJTA4eCIsCi0JCSAgICAodWludG1heF90ICliZTY0dG9oKGlkKSwgbnRvaGwocy0+Y3Jl YXRvcmlkKSk7CisJCSAgICAodWludG1heF90KWJlNjR0b2gocy0+aWQpLCBudG9obChzLT5jcmVh dG9yaWQpKTsKIAkJcHJpbnRmKCJcbiIpOwogCX0KIH0KSW5kZXg6IHNiaW4vcGZjdGwvcGZjdGwu Ywo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09Ci0tLSBzYmluL3BmY3RsL3BmY3RsLmMJKHJldmlzaW9uIDI2MDQ5MikKKysr IHNiaW4vcGZjdGwvcGZjdGwuYwkod29ya2luZyBjb3B5KQpAQCAtMTA1NCw4ICsxMDU0LDggQEAg ZG9uZToKIGludAogcGZjdGxfc2hvd19zdGF0ZXMoaW50IGRldiwgY29uc3QgY2hhciAqaWZhY2Us IGludCBvcHRzKQogewotCXN0cnVjdCBwZmlvY19zdGF0ZXMgcHM7Ci0Jc3RydWN0IHBmc3luY19z dGF0ZSAqcDsKKwlzdHJ1Y3QgcGZpb2Nfc3RhdGVzMiBwczsKKwlzdHJ1Y3QgcGZpb2Nfc3RhdGUy ICpwOwogCWNoYXIgKmluYnVmID0gTlVMTCwgKm5ld2luYnVmID0gTlVMTDsKIAl1bnNpZ25lZCBp bnQgbGVuID0gMDsKIAlpbnQgaSwgZG90aXRsZSA9IChvcHRzICYgUEZfT1BUX1NIT1dBTEwpOwpA QCAtMTA2OSwxMiArMTA2OSwxMiBAQCBwZmN0bF9zaG93X3N0YXRlcyhpbnQgZGV2LCBjb25zdCBj aGFyICppZmFjZSwgaW50CiAJCQkJZXJyKDEsICJyZWFsbG9jIik7CiAJCQlwcy5wc19idWYgPSBp bmJ1ZiA9IG5ld2luYnVmOwogCQl9Ci0JCWlmIChpb2N0bChkZXYsIERJT0NHRVRTVEFURVMsICZw cykgPCAwKSB7Ci0JCQl3YXJuKCJESU9DR0VUU1RBVEVTIik7CisJCWlmIChpb2N0bChkZXYsIERJ T0NHRVRTVEFURVMyLCAmcHMpIDwgMCkgeworCQkJd2FybigiRElPQ0dFVFNUQVRFUzIiKTsKIAkJ CWZyZWUoaW5idWYpOwogCQkJcmV0dXJuICgtMSk7CiAJCX0KLQkJaWYgKHBzLnBzX2xlbiArIHNp emVvZihzdHJ1Y3QgcGZpb2Nfc3RhdGVzKSA8IGxlbikKKwkJaWYgKHBzLnBzX2xlbiArIHNpemVv ZihzdHJ1Y3QgcGZpb2Nfc3RhdGVzMikgPCBsZW4pCiAJCQlicmVhazsKIAkJaWYgKGxlbiA9PSAw ICYmIHBzLnBzX2xlbiA9PSAwKQogCQkJZ290byBkb25lOwpJbmRleDogc2Jpbi9wZmN0bC9wZmN0 bC5oCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT0KLS0tIHNiaW4vcGZjdGwvcGZjdGwuaAkocmV2aXNpb24gMjYwNDkyKQor Kysgc2Jpbi9wZmN0bC9wZmN0bC5oCSh3b3JraW5nIGNvcHkpCkBAIC0xMTcsOCArMTE3LDggQEAg Y2hhcgkJKnJhdGUyc3RyKGRvdWJsZSk7CiAKIHZvaWQJIHByaW50X2FkZHIoc3RydWN0IHBmX2Fk ZHJfd3JhcCAqLCBzYV9mYW1pbHlfdCwgaW50KTsKIHZvaWQJIHByaW50X2hvc3Qoc3RydWN0IHBm X2FkZHIgKiwgdV9pbnQxNl90IHAsIHNhX2ZhbWlseV90LCBpbnQpOwotdm9pZAkgcHJpbnRfc2Vx KHN0cnVjdCBwZnN5bmNfc3RhdGVfcGVlciAqKTsKLXZvaWQJIHByaW50X3N0YXRlKHN0cnVjdCBw ZnN5bmNfc3RhdGUgKiwgaW50KTsKK3ZvaWQJIHByaW50X3NlcShzdHJ1Y3QgcGZpb2Nfc3RhdGUy X3BlZXIgKik7Cit2b2lkCSBwcmludF9zdGF0ZShzdHJ1Y3QgcGZpb2Nfc3RhdGUyICosIGludCk7 CiBpbnQJIHVubWFzayhzdHJ1Y3QgcGZfYWRkciAqLCBzYV9mYW1pbHlfdCk7CiAKIGludAkgcGZj dGxfY21kbGluZV9zeW1zZXQoY2hhciAqKTsK --089e0160c35e9e329d04efb94ed2 Content-Type: application/octet-stream; name="pfctl-constify.patch" Content-Disposition: attachment; filename="pfctl-constify.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hqbfbpwr1 LS0tIHNiaW4vcGZjdGwvcGZjdGwuaC5vcmlnCTIwMTQtMDEtMTEgMjE6MjA6NTcuMDAwMDAwMDAw ICswMjAwCisrKyBzYmluL3BmY3RsL3BmY3RsLmgJMjAxNC0wMS0xMSAyMToyMjozMC4wMDAwMDAw MDAgKzAyMDAKQEAgLTExNSwxMSArMTE1LDExIEBAIHZvaWQJCSBwZmFsdHFfc3RvcmUoc3RydWN0 IHBmX2FsdHEgKik7CiBzdHJ1Y3QgcGZfYWx0cQkqcGZhbHRxX2xvb2t1cChjb25zdCBjaGFyICop OwogY2hhcgkJKnJhdGUyc3RyKGRvdWJsZSk7CiAKLXZvaWQJIHByaW50X2FkZHIoc3RydWN0IHBm X2FkZHJfd3JhcCAqLCBzYV9mYW1pbHlfdCwgaW50KTsKLXZvaWQJIHByaW50X2hvc3Qoc3RydWN0 IHBmX2FkZHIgKiwgdV9pbnQxNl90IHAsIHNhX2ZhbWlseV90LCBpbnQpOwotdm9pZAkgcHJpbnRf c2VxKHN0cnVjdCBwZmlvY19zdGF0ZTJfcGVlciAqKTsKLXZvaWQJIHByaW50X3N0YXRlKHN0cnVj dCBwZmlvY19zdGF0ZTIgKiwgaW50KTsKLWludAkgdW5tYXNrKHN0cnVjdCBwZl9hZGRyICosIHNh X2ZhbWlseV90KTsKK3ZvaWQJIHByaW50X2FkZHIoY29uc3Qgc3RydWN0IHBmX2FkZHJfd3JhcCAq LCBzYV9mYW1pbHlfdCwgaW50KTsKK3ZvaWQJIHByaW50X2hvc3QoY29uc3Qgc3RydWN0IHBmX2Fk ZHIgKiwgdV9pbnQxNl90IHAsIHNhX2ZhbWlseV90LCBpbnQpOwordm9pZAkgcHJpbnRfc2VxKGNv bnN0IHN0cnVjdCBwZmlvY19zdGF0ZTJfcGVlciAqKTsKK3ZvaWQJIHByaW50X3N0YXRlKGNvbnN0 IHN0cnVjdCBwZmlvY19zdGF0ZTIgKiwgaW50KTsKK2ludAkgdW5tYXNrKGNvbnN0IHN0cnVjdCBw Zl9hZGRyICosIHNhX2ZhbWlseV90KTsKIAogaW50CSBwZmN0bF9jbWRsaW5lX3N5bXNldChjaGFy ICopOwogaW50CSBwZmN0bF9hZGRfdHJhbnMoc3RydWN0IHBmcl9idWZmZXIgKiwgaW50LCBjb25z dCBjaGFyICopOwotLS0gc2Jpbi9wZmN0bC9wZmN0bF9wYXJzZXIuaC5vcmlnCTIwMTQtMDEtMTEg MTQ6MDA6MTMuMDAwMDAwMDAwICswMjAwCisrKyBzYmluL3BmY3RsL3BmY3RsX3BhcnNlci5oCTIw MTQtMDEtMTEgMjE6Mzc6MDIuMDAwMDAwMDAwICswMjAwCkBAIC0yOTIsNyArMjkyLDcgQEAgZXh0 ZXJuIGNvbnN0IHN0cnVjdCBwZl90aW1lb3V0IHBmX3RpbWVvdQogCiB2b2lkCQkJIHNldF9pcG1h c2soc3RydWN0IG5vZGVfaG9zdCAqLCB1X2ludDhfdCk7CiBpbnQJCQkgY2hlY2tfbmV0bWFzayhz dHJ1Y3Qgbm9kZV9ob3N0ICosIHNhX2ZhbWlseV90KTsKLWludAkJCSB1bm1hc2soc3RydWN0IHBm X2FkZHIgKiwgc2FfZmFtaWx5X3QpOworaW50CQkJIHVubWFzayhjb25zdCBzdHJ1Y3QgcGZfYWRk ciAqLCBzYV9mYW1pbHlfdCk7CiB2b2lkCQkJIGlmYV9sb2FkKHZvaWQpOwogc3RydWN0IG5vZGVf aG9zdAkqaWZhX2V4aXN0cyhjb25zdCBjaGFyICopOwogc3RydWN0IG5vZGVfaG9zdAkqaWZhX2xv b2t1cChjb25zdCBjaGFyICosIGludCk7Ci0tLSBzYmluL3BmY3RsL3BmX3ByaW50X3N0YXRlLmMu b3JpZwkyMDE0LTAxLTExIDIxOjIxOjMwLjAwMDAwMDAwMCArMDIwMAorKysgc2Jpbi9wZmN0bC9w Zl9wcmludF9zdGF0ZS5jCTIwMTQtMDEtMTEgMjE6Mzg6MTUuMDAwMDAwMDAwICswMjAwCkBAIC01 MCwxMCArNTAsMTAgQEAgX19GQlNESUQoIiRGcmVlQlNEOiByZWxlbmcvMTAuMC9zYmluL3BmYwog I2luY2x1ZGUgInBmY3RsX3BhcnNlci5oIgogI2luY2x1ZGUgInBmY3RsLmgiCiAKLXZvaWQJcHJp bnRfbmFtZShzdHJ1Y3QgcGZfYWRkciAqLCBzYV9mYW1pbHlfdCk7Cit2b2lkCXByaW50X25hbWUo Y29uc3Qgc3RydWN0IHBmX2FkZHIgKiwgc2FfZmFtaWx5X3QpOwogCiB2b2lkCi1wcmludF9hZGRy KHN0cnVjdCBwZl9hZGRyX3dyYXAgKmFkZHIsIHNhX2ZhbWlseV90IGFmLCBpbnQgdmVyYm9zZSkK K3ByaW50X2FkZHIoY29uc3Qgc3RydWN0IHBmX2FkZHJfd3JhcCAqYWRkciwgc2FfZmFtaWx5X3Qg YWYsIGludCB2ZXJib3NlKQogewogCXN3aXRjaCAoYWRkci0+dHlwZSkgewogCWNhc2UgUEZfQURE Ul9EWU5JRlRMOgpAQCAtMTM0LDcgKzEzNCw3IEBAIHByaW50X2FkZHIoc3RydWN0IHBmX2FkZHJf d3JhcCAqYWRkciwgc2EKIH0KIAogdm9pZAotcHJpbnRfbmFtZShzdHJ1Y3QgcGZfYWRkciAqYWRk ciwgc2FfZmFtaWx5X3QgYWYpCitwcmludF9uYW1lKGNvbnN0IHN0cnVjdCBwZl9hZGRyICphZGRy LCBzYV9mYW1pbHlfdCBhZikKIHsKIAljaGFyIGhvc3RbTklfTUFYSE9TVF07CiAKQEAgLTE2Nyw3 ICsxNjcsNyBAQCBwcmludF9uYW1lKHN0cnVjdCBwZl9hZGRyICphZGRyLCBzYV9mYW1pCiB9CiAK IHZvaWQKLXByaW50X2hvc3Qoc3RydWN0IHBmX2FkZHIgKmFkZHIsIHVfaW50MTZfdCBwb3J0LCBz YV9mYW1pbHlfdCBhZiwgaW50IG9wdHMpCitwcmludF9ob3N0KGNvbnN0IHN0cnVjdCBwZl9hZGRy ICphZGRyLCB1X2ludDE2X3QgcG9ydCwgc2FfZmFtaWx5X3QgYWYsIGludCBvcHRzKQogewogCWlm IChvcHRzICYgUEZfT1BUX1VTRUROUykKIAkJcHJpbnRfbmFtZShhZGRyLCBhZik7CkBAIC0xOTQs NyArMTk0LDcgQEAgcHJpbnRfaG9zdChzdHJ1Y3QgcGZfYWRkciAqYWRkciwgdV9pbnQxNgogfQog CiB2b2lkCi1wcmludF9zZXEoc3RydWN0IHBmaW9jX3N0YXRlMl9wZWVyICpwKQorcHJpbnRfc2Vx KGNvbnN0IHN0cnVjdCBwZmlvY19zdGF0ZTJfcGVlciAqcCkKIHsKIAlpZiAocC0+c2VxZGlmZikK IAkJcHJpbnRmKCJbJXUgKyAldV0oKyV1KSIsIHAtPnNlcWxvLCBwLT5zZXFoaSAtIHAtPnNlcWxv LApAQCAtMjA0LDEyICsyMDQsMTMgQEAgcHJpbnRfc2VxKHN0cnVjdCBwZmlvY19zdGF0ZTJfcGVl ciAqcCkKIH0KIAogdm9pZAotcHJpbnRfc3RhdGUoc3RydWN0IHBmaW9jX3N0YXRlMiAqcywgaW50 IG9wdHMpCitwcmludF9zdGF0ZShjb25zdCBzdHJ1Y3QgcGZpb2Nfc3RhdGUyICpzLCBpbnQgb3B0 cykKIHsKLQlzdHJ1Y3QgcGZpb2Nfc3RhdGUyX3BlZXIgKnNyYywgKmRzdDsKLQlzdHJ1Y3QgcGZp b2Nfc3RhdGUyX2tleSAqc2ssICpuazsKLQlzdHJ1Y3QgcHJvdG9lbnQgKnA7CisJY29uc3Qgc3Ry dWN0IHBmaW9jX3N0YXRlMl9wZWVyICpzcmMsICpkc3Q7CisJY29uc3Qgc3RydWN0IHBmaW9jX3N0 YXRlMl9rZXkgKnNrLCAqbms7CisJY29uc3Qgc3RydWN0IHByb3RvZW50ICpwOwogCWludCBtaW4s IHNlYzsKKwl1X2ludDE2X3Qgc3BvcnRbMl0sIG5wb3J0WzJdOwogCiAJaWYgKHMtPmRpcmVjdGlv biA9PSBQRl9PVVQpIHsKIAkJc3JjID0gJnMtPnNyYzsKQEAgLTIxNywxNCArMjE4LDI0IEBAIHBy aW50X3N0YXRlKHN0cnVjdCBwZmlvY19zdGF0ZTIgKnMsIGludCAKIAkJc2sgPSAmcy0+a2V5W1BG X1NLX1NUQUNLXTsKIAkJbmsgPSAmcy0+a2V5W1BGX1NLX1dJUkVdOwogCQlpZiAocy0+cHJvdG8g PT0gSVBQUk9UT19JQ01QIHx8IHMtPnByb3RvID09IElQUFJPVE9fSUNNUFY2KSAKLQkJCXNrLT5w b3J0WzBdID0gbmstPnBvcnRbMF07CisJCQlzcG9ydFswXSA9IG5rLT5wb3J0WzBdOworCQllbHNl CisJCQlzcG9ydFswXSA9IHNrLT5wb3J0WzBdOworCQlzcG9ydFsxXSA9IHNrLT5wb3J0WzFdOwor CQlucG9ydFswXSA9IG5rLT5wb3J0WzBdOworCQlucG9ydFsxXSA9IG5rLT5wb3J0WzFdOwogCX0g ZWxzZSB7CiAJCXNyYyA9ICZzLT5kc3Q7CiAJCWRzdCA9ICZzLT5zcmM7CiAJCXNrID0gJnMtPmtl eVtQRl9TS19XSVJFXTsKIAkJbmsgPSAmcy0+a2V5W1BGX1NLX1NUQUNLXTsKKwkJc3BvcnRbMF0g PSBzay0+cG9ydFswXTsKIAkJaWYgKHMtPnByb3RvID09IElQUFJPVE9fSUNNUCB8fCBzLT5wcm90 byA9PSBJUFBST1RPX0lDTVBWNikgCi0JCQlzay0+cG9ydFsxXSA9IG5rLT5wb3J0WzFdOworCQkJ c3BvcnRbMV0gPSBuay0+cG9ydFsxXTsKKwkJZWxzZQorCQkJc3BvcnRbMV0gPSBzay0+cG9ydFsx XTsKKwkJbnBvcnRbMF0gPSBuay0+cG9ydFswXTsKKwkJbnBvcnRbMV0gPSBuay0+cG9ydFsxXTsK IAl9CiAJcHJpbnRmKCIlcyAiLCBzLT5pZm5hbWUpOwogCWlmICgocCA9IGdldHByb3RvYnludW1i ZXIocy0+cHJvdG8pKSAhPSBOVUxMKQpAQCAtMjMyLDIyICsyNDMsMjIgQEAgcHJpbnRfc3RhdGUo c3RydWN0IHBmaW9jX3N0YXRlMiAqcywgaW50IAogCWVsc2UKIAkJcHJpbnRmKCIldSAiLCBzLT5w cm90byk7CiAKLQlwcmludF9ob3N0KCZuay0+YWRkclsxXSwgbmstPnBvcnRbMV0sIHMtPmFmLCBv cHRzKTsKKwlwcmludF9ob3N0KCZuay0+YWRkclsxXSwgbnBvcnRbMV0sIHMtPmFmLCBvcHRzKTsK IAlpZiAoUEZfQU5FUSgmbmstPmFkZHJbMV0sICZzay0+YWRkclsxXSwgcy0+YWYpIHx8Ci0JICAg IG5rLT5wb3J0WzFdICE9IHNrLT5wb3J0WzFdKSB7CisJICAgIG5wb3J0WzFdICE9IHNwb3J0WzFd KSB7CiAJCXByaW50ZigiICgiKTsKLQkJcHJpbnRfaG9zdCgmc2stPmFkZHJbMV0sIHNrLT5wb3J0 WzFdLCBzLT5hZiwgb3B0cyk7CisJCXByaW50X2hvc3QoJnNrLT5hZGRyWzFdLCBzcG9ydFsxXSwg cy0+YWYsIG9wdHMpOwogCQlwcmludGYoIikiKTsKIAl9CiAJaWYgKHMtPmRpcmVjdGlvbiA9PSBQ Rl9PVVQpCiAJCXByaW50ZigiIC0+ICIpOwogCWVsc2UKIAkJcHJpbnRmKCIgPC0gIik7Ci0JcHJp bnRfaG9zdCgmbmstPmFkZHJbMF0sIG5rLT5wb3J0WzBdLCBzLT5hZiwgb3B0cyk7CisJcHJpbnRf aG9zdCgmbmstPmFkZHJbMF0sIG5wb3J0WzBdLCBzLT5hZiwgb3B0cyk7CiAJaWYgKFBGX0FORVEo Jm5rLT5hZGRyWzBdLCAmc2stPmFkZHJbMF0sIHMtPmFmKSB8fAotCSAgICBuay0+cG9ydFswXSAh PSBzay0+cG9ydFswXSkgeworCSAgICBucG9ydFswXSAhPSBzcG9ydFswXSkgewogCQlwcmludGYo IiAoIik7Ci0JCXByaW50X2hvc3QoJnNrLT5hZGRyWzBdLCBzay0+cG9ydFswXSwgcy0+YWYsIG9w dHMpOworCQlwcmludF9ob3N0KCZzay0+YWRkclswXSwgc3BvcnRbMF0sIHMtPmFmLCBvcHRzKTsK IAkJcHJpbnRmKCIpIik7CiAJfQogCkBAIC0zMzIsNyArMzQzLDcgQEAgcHJpbnRfc3RhdGUoc3Ry dWN0IHBmaW9jX3N0YXRlMiAqcywgaW50IAogfQogCiBpbnQKLXVubWFzayhzdHJ1Y3QgcGZfYWRk ciAqbSwgc2FfZmFtaWx5X3QgYWYpCit1bm1hc2soY29uc3Qgc3RydWN0IHBmX2FkZHIgKm0sIHNh X2ZhbWlseV90IGFmKQogewogCWludCBpID0gMzEsIGogPSAwLCBiID0gMDsKIAl1X2ludDMyX3Qg dG1wOwo= --089e0160c35e9e329d04efb94ed2--