From owner-freebsd-net@FreeBSD.ORG Sun Jan 6 00:30:33 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0199316A417 for ; Sun, 6 Jan 2008 00:30:33 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outT.internet-mail-service.net (outT.internet-mail-service.net [216.240.47.243]) by mx1.freebsd.org (Postfix) with ESMTP id DC9C113C468 for ; Sun, 6 Jan 2008 00:30:32 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Sat, 05 Jan 2008 16:30:32 -0800 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id CE863126E27; Sat, 5 Jan 2008 16:30:30 -0800 (PST) Message-ID: <47802137.8020701@elischer.org> Date: Sat, 05 Jan 2008 16:30:47 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Vadim Goncharov References: <4772F123.5030303@elischer.org> <477416CC.4090906@elischer.org> <477D2EF3.2060909@elischer.org> In-Reply-To: Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org, Ivo Vachkov , Robert Watson , Qing Li , FreeBSD Net Subject: Re: resend: multiple routing table roadmap (format fix) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2008 00:30:33 -0000 Vadim Goncharov wrote: > 04.01.08 @ 00:52 Julian Elischer wrote: > >>>> By the way, I might add that in the 6.x compat. version I may end up >>>> limiting the feature to 8 tables. This is because I need to store some >>>> stuff in an efficient way in the mbuf, and in a compatible manner >>>> this is easiest done by stealing the top 4 bits in the mbuf dlags word >>>> and defining them as: >>>> >>>> #define M_HAVEFIB 0x10000000 >>>> #define M_FIBMASK 0x07 >>>> #define M_FIBNUM 0xe0000000 >>>> #define M_FIBSHIFT 29 >>>> #define m_getfib(_m, _default) ((m->m_flags & M_HAVE_FIBNUM) ? >>>> ((m->m_flags >> M_FIBSHIFT) & M_FIBMASK) : _default) >>>> #M_SETFIB(_m, _fib) do { \ >>>> _m->m_flags &= ~M_FIBNUM; \ >>>> _m->m_flags |= (M_HAVEFIB|((_fib & M_FIBMASK) << M_FIBSHIFT));\ >>>> } while (0) >>>> >>>> This then becomes very easy to change to use a tag or >>>> whatever is needed in later versions , and the number can >>>> be expanded past 8 predefined FIBs at that time.. >>> If you want it to be a tag, why spent bits in m_flags and not just >>> do it as a tag at once? Or it is supposed to completely throw away >>> 6.x (possibly 7.x too) implementation in favor of right thing in 8.0 ? >> >> basically yes.. >> >> I'm looking at just doing tags to start with, but haven't done it >> yet.. I'm looking for a good bit of tag code to copy :-) > > Look at ipfw's O_ALTQ/O_TAG/O_TAGGED (ands some other parts), ng_tag.c, > ng_ipfw.c, ng_ksocket.c and some other stuff :-) Tags are simple, if 16 > bits are enough to you then even do not have to allocate data, just use > tag_id member. Also they are easy to manipulate within netgraph with > ng_tag, etc. But as drawback - you have to allocate memory for them, an > as it is M_NOWAIT, malloc() can return NULL in interrupt threads... So a > new field in mbuf (or flags) would be better in terms of performance, > but it will break ABI :( so that may happen later.. this code is specifically to not break ABIs. The tag method worries me as overhead for potentially every packet might bee too much. In mbuf field is the delux solution. > > I don't have m_tag_alloc() measurements, though. Doing 'ipfw add 1 tag 1 > ip from any to any' on a 15 kpps 6.2 router didn't cause any noticeable > slowdown while looking for half a minute at 'systat -vm 1'... that already has ipfw overhead. it may be noticable if you are coparing adding and reading tags in a data path with no ipfw overhead. > >> setfib 3 /bin/sh >> >> now by default everythign you do uses table 3. >> or even >> >> setfib 3 jail {blah} >> >> and all the procs in the jail use table 3. You also need to do >> setfib 3 jexec xxx >> for extra processes you add to the jail afterwards. > > May be introduce a field in a struct prison to make it possible without > additional commands? yes it's in my original description email that that may be an option. > >>>>>> 2/ packets received on an interface for forwarding. >>>>>> By default these packets would use table 0, >>>>>> (or possibly a number settable in a sysctl(not yet)). >>>>>> but prior to routing the firewall can inspect them (see below). >>>>>> >>>>>> 3/ packets inspected by a packet classifier, which can arbitrarily >>>>>> associate a fib with it on a packet by packet basis. >>>>>> A fib assigned to a packet by a packet classifier >>>>>> (such as ipfw) would over-ride a fib associated by >>>>>> a more default source. (such as cases 1 or 2). >>> Sounds good. I like idea to do routing decisions in firewall, to not >>> double kernel code and userspace utilities, like in Linux' iproute2 >>> (which, however, still have a few parameters and relies on firewall >>> marks for others). However, there are some cases, I think, where it >>> could be done outisde firewall. For example, make an ifconfig option >>> to use a specific FIB as a default for all packets outgoing from this >>> interface's address. But here arises another related question - Linux >>> allows to select a specific src IP based on a routing table entry - >>> destination address (thoughts about pf reply-to/route-ro, huh). >> >> that is default here too if I understand what you are talking about. >> teh src address is selected from the routing table's exit interface. >> In the code I'm showing in perforce, that address would depend on >> which table your process was associated with. (or just the socket if >> you have used the socket option on it before doing the bind/connect) > > What I'm talking about is adding possibility for future MPLS/VRF/etc. > For example, if we make an interface option to use a specific FIB on > that interface, for every incoming packet (put a tag on early input?), > then ARP replies, ICMP redirects (yes, make stack to process them to > particular FIB if specified, not to main) and so on will affect only > this table. Then, it will be possible, say, to have 192.168.0.0/24 on > em0 and also have 192.168.0.0/24 on em1, but that networks are > completely independent of each other on both L2 and L3 (different > customers) - after that, a change allowing to have the same IP address > on different interfaces will lead to complete virtual independence. > Without any vimages - why do we need separate TCP stacks etc. copies on > a router without any jails, under a single administrator's control? > > Yes, this may be difficult with planned L2/L3 separation (currently ARP > table is in fact part of FIB), but it is solvable - say, by binding an > ARP table to one or several FIBs. Moreover, I think that complete stack > virtulization in each jail/vimage is waste of resources - instead one or > several FIBs/interfaces/ARP tables can be bound to each vimage/jail, > possibly with write permissions. I'm a great believer of vimage. I don't want to duplicate that functionality. > > And even all of above is considered a far future and/or will be made > different way, FIB binding to interface is still useful for (both > incoming and) outgoing packets to make a firewall ruleset simpler. "maybe" > >>> In relation to this I can remember multipath routing (different >>> metrics?), addresses from one subnet on different ifaces (mask wider >>> /32) and so on. >>> Also it is interesting, how multiple FIBs would interact with >>> host-wide events, such as ICMP redirects (which table should be >>> updated?), storing of TCP stack metrics (MTU, etc.) and hostcache, >>> and so on. How these and above will be solved?.. >> >> I'm not really too knowledgeable about multicast.. typo .. I meant multipath. > > Is multicast and multipath routing the same? > >>> per ifconfig (>1 host per subnet)/icmp redirects/src to prefer, >>> multipath/metrics, tcp stack parameters interaction, iproute2 >> >> I'm not trying to solve problems that need vimage to solve them.. > > Umm, what vimage?.. :) I forgot to clear these keywords written for > myself when writing draft and expaining them in detail,sorry :) Marko's vimage code solves much of this in a much cleaner manner. I'm hoping that we will eventually have multiple routing tables in multiple vimages. > >>>>>> Routing messages would be associated with their >>>>>> process, and thus select one FIB or another. >>> This is not clear. How should the 'route' command work with >>> different FIBs, if they are supposed by admin to be used for >>> forwarding, and not the straight per-process? I think a setfib option >>> is more consistent than running route under setfib command. Also, >>> routing sockets and routing daemons - should they work with only one >>> table?.. >> >> if you do >> setfib 3 route get 1.1.1.1 >> >> you may get a different result from >> >> setfib 2 route get 1.1.1.1 >> >> I will add a fibnum argument to route itself as well but it's not >> needed immediately as long as I have the setfib command. > > OK, but we should think about it in the future. In theory, routing > socket's messages are easily extendable with FIB number in uint16_t, as > message keeps it's length... I will do that with the advice of people who know that protocol better than I do. > >>>>>> I have not yet added the changes to ipfw. >>> Action modifier, like 'ipfw add count setfib 3 ip from any to any' ? >>> There were thoughts (I heard,t as a hack before multiple FIBs) about >>> making an additional, say, 'nexthop' ipfw action, which acts like >>> fwd, but does not accept packet, allowing to continue it through >>> firewall ruleset - thus making it more comfortable to separate >>> routing (imagine 'nexthop tablearg') and filtering. There are >>> questions with both fwd and new supposed option: will fwd still >>> survive? Will it change the output interface, like as complete >>> rerouting before calling pfil(9) hooks, so that *oif will be changed >>> to be mathed iin rules below? pf route-to/reply-to is hanging around... >> >> The 'nexthop' cal you suggest is problematic because it needs to >> return information immediately. which is why it is terminal. > > Um, why? Why it can't continue through ruleset? I don't know > implementation details of routing and 'ipfw fwd', alas, the way the nexthop/fwd command is implemented, the rule needs to return to the caller immediatly. > >> As for the setfib ipfw action, I have now done this in p4. >> >> ipfw add 200 setfib 3 ip from any to any in receive em0 >> >> now works. >> This lessens the need for associating a fib with an interface as the >> firewall can do that too.. >> >> the setfib rule is not terminal. (hmm need to check I did that right.) > > Oh, it it works, that's cool. > >> you can also do >> ipfw add 200 skipto 300 ip from any to any hasfib >> # to select on a packet that has a fib associated with it already. >> ipfw add 200 skipto 300 ip from any to any fib 4 >> # to slelect packets that are associated with fib 4 >> ipfw add 200 clrfib ip from any to any >> # to remove a fib association from the packet. > > Do we need a separate keyword 'clrfib' while it could be 'setfib 0' ? Or > at least save one opcode in kernel's ipfw. Also, it would be nice to > have 'setfib tablearg' together with reserving 16 bits for FIB number - > some systems with hundreds of vlans will want to have more than 256 > tables, I think... having an override fib is differnt from having a fib of 0. I'm not sure about tablearg yet.. I've considered it but not in the first version.. > >>>>>> Interaction with the ARP layer/ LL layer would need to be >>>>>> revisited as well. Qing Li has been working on this already. >>> Oh yes, L2 interaction is interesting. How it should work in case of >>> planned separation of routing and ARP tables?.. > > I've explained my views about it above... > From owner-freebsd-net@FreeBSD.ORG Sun Jan 6 01:19:49 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B41B16A41A for ; Sun, 6 Jan 2008 01:19:49 +0000 (UTC) (envelope-from trashy_bumper@yahoo.com) Received: from web36315.mail.mud.yahoo.com (web36315.mail.mud.yahoo.com [209.191.91.192]) by mx1.freebsd.org (Postfix) with SMTP id 41B4713C45B for ; Sun, 6 Jan 2008 01:19:48 +0000 (UTC) (envelope-from trashy_bumper@yahoo.com) Received: (qmail 64828 invoked by uid 60001); 6 Jan 2008 01:19:48 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=zHV5UqtbhkT0homDlkF3QNG4T0vl5N90/2zyBylX2+Upr5Bi7yXiVGZfos3Rvr3XpsLwng2FR2901+bPNsIAHq0cByC2KNOWHQeSIXFkWL2EMh1PstSCcVxR6PkvDqy4c3dInMgPqZjfGxwWYxyx7z90ospNXynYOBINFR8zStE=; X-YMail-OSG: A.NWnfsVM1nHKhI_TmT_.MFU7aFdCgxnkKlP2ZFkHl_jVV2Tt8eWbSw58agz1BSelg-- Received: from [82.144.207.13] by web36315.mail.mud.yahoo.com via HTTP; Sat, 05 Jan 2008 17:19:47 PST X-Mailer: YahooMailRC/818.31 YahooMailWebService/0.7.158.1 Date: Sat, 5 Jan 2008 17:19:47 -0800 (PST) From: Nash Nipples To: freebsd-net@freebsd.org MIME-Version: 1.0 Message-ID: <133740.64664.qm@web36315.mail.mud.yahoo.com> Content-Type: text/plain; charset=us-ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: looking for dual-phy (copper & fiber) NIC X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2008 01:19:49 -0000 Dear Aaron, i give up on searching for a Dual-phy copper fiber gigabit nic. the search terminates at this 2004 article http://www.thefreelibrary.com/Ixia+Introduces+Dual-PHY+Copper%2FFiber-Optic+Gigabit+Ethernet+Testing...-a0112895579 assumption would be that Allied Telesis have made a successfull hybridus at 100bps and when things went closer to 1000bps vendors have decided to invest into media converters. these are available stand-alone or slide-in (Transition Networks for example). sincerely, nash p.s. please send a note if you ever find one ----- Original Message ---- From: Aaron Turner To: freebsd-net@freebsd.org Sent: Saturday, January 5, 2008 10:30:43 PM Subject: looking for dual-phy (copper & fiber) NIC Sorry for the slightly OT, but I've run out of ideas... I could of sworn about a month ago or so, I found a half-height gigabit NIC (PCI Express I think) which offered two copper AND two SFP connectors for fiber. The card had only two ethernet controllers (Marvell I think), hence you could only use up to two connectors at any time. Very similar to many switches which give you the choice of copper or fiber but not both (sometimes called "combo ports"). Of course, I didn't bookmark the page, I can't find it in my browser history and Google is failing me horribly. Note: I'm NOT looking for the old SysKonnect or Allied Tellysn cards which are 10/100Mbps. This was a gigabit card! Any hints or pointers to the page, vendor or reseller would be greatly appreciated. Thanks, Aaron -- Aaron Turner http://synfin.net/ http://tcpreplay.synfin.net/ - Pcap editing & replay tools for Unix They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin _______________________________________________ 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" ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs From owner-freebsd-net@FreeBSD.ORG Sun Jan 6 03:01:49 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3974B16A417 for ; Sun, 6 Jan 2008 03:01:49 +0000 (UTC) (envelope-from toasty@dragondata.com) Received: from tokyo01.jp.mail.your.org (tokyo01.jp.mail.your.org [204.9.54.5]) by mx1.freebsd.org (Postfix) with ESMTP id F2B9713C459 for ; Sun, 6 Jan 2008 03:01:48 +0000 (UTC) (envelope-from toasty@dragondata.com) Received: from mail.your.org (server3-a.your.org [64.202.112.67]) by tokyo01.jp.mail.your.org (Postfix) with ESMTP id 3BB532AD541F; Sun, 6 Jan 2008 02:29:35 +0000 (UTC) Received: from pool011.dhcp.your.org (pool011.dhcp.your.org [69.31.99.11]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.your.org (Postfix) with ESMTP id 8614FA0A44F; Sun, 6 Jan 2008 02:29:34 +0000 (UTC) Message-Id: <36C5325A-7B94-4094-B843-DBAED2D57B3D@dragondata.com> From: Kevin Day To: "Aaron Turner" In-Reply-To: <1ca1c1410801051230l49fa523cicb3f9f9394214701@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Sat, 5 Jan 2008 20:29:34 -0600 References: <1ca1c1410801051230l49fa523cicb3f9f9394214701@mail.gmail.com> X-Mailer: Apple Mail (2.915) Cc: freebsd-net@freebsd.org Subject: Re: looking for dual-phy (copper & fiber) NIC X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2008 03:01:49 -0000 On Jan 5, 2008, at 2:30 PM, Aaron Turner wrote: > Sorry for the slightly OT, but I've run out of ideas... > > I could of sworn about a month ago or so, I found a half-height > gigabit NIC (PCI Express I think) which offered two copper AND two SFP > connectors for > fiber. The card had only two ethernet controllers (Marvell I think), > hence you could only use up to two connectors at any time. Very > similar to many switches which give you the choice of copper or fiber > but not both (sometimes called "combo ports"). > > Of course, I didn't bookmark the page, I can't find it in my browser > history and Google is failing me horribly. Note: I'm NOT looking for > the old SysKonnect or Allied Tellysn cards which are 10/100Mbps. This > was a gigabit card! > > Any hints or pointers to the page, vendor or reseller would be greatly > appreciated. > I know this isn't what you're looking for, but what about buying a 2 port SFP gigabit card, and putting a copper SFP and a fiber SFP in? http://www.dssnetworks.com/v3/gigabit_pci_6267.asp That should work with the "em" driver I believe, and you can stuff whichever kind of SFP you want in it. Copper SFPs are pretty cheap... http://www.finisar.com/product-160-1000BASE-T_Copper_SFP_(FCMJ-8521-3_8520-3) While I'm not saying I don't believe what you're describing exists, I'm having trouble picturing how you could fit 2 RJ48 and 2 SFP slots on a half height card. -- Kevin From owner-freebsd-net@FreeBSD.ORG Sun Jan 6 05:10:10 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E111D16A418 for ; Sun, 6 Jan 2008 05:10:09 +0000 (UTC) (envelope-from cristclark@comcast.net) Received: from QMTA09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by mx1.freebsd.org (Postfix) with ESMTP id 8538213C478 for ; Sun, 6 Jan 2008 05:10:09 +0000 (UTC) (envelope-from cristclark@comcast.net) Received: from OMTA04.westchester.pa.mail.comcast.net ([76.96.62.35]) by QMTA09.westchester.pa.mail.comcast.net with comcast id ZRck1Y00H0ldTLk590tC00; Sun, 06 Jan 2008 04:59:08 +0000 Received: from goku.pumpky.net ([24.6.98.159]) by OMTA04.westchester.pa.mail.comcast.net with comcast id Zgz31Y00N3SKeAY3Q00000; Sun, 06 Jan 2008 04:59:05 +0000 X-Authority-Analysis: v=1.0 c=1 a=6I5d2MoRAAAA:8 a=wNfJbO0RzeBm1DB5M-sA:9 a=4V1kW-f_dGEW1hCOaNEA:7 a=HRnS0dUMhES-omimw5hDAB5hH1AA:4 a=SV7veod9ZcQA:10 a=LY0hPdMaydYA:10 Received: from goku.pumpky.net (localhost. [127.0.0.1]) by goku.pumpky.net (8.13.8/8.13.8) with ESMTP id m064x6k9001929; Sat, 5 Jan 2008 20:59:06 -0800 (PST) (envelope-from cristclark@comcast.net) Received: (from cjc@localhost) by goku.pumpky.net (8.13.8/8.13.8/Submit) id m064x4rx001928; Sat, 5 Jan 2008 20:59:04 -0800 (PST) (envelope-from cristclark@comcast.net) X-Authentication-Warning: goku.cjclark.org: cjc set sender to cristclark@comcast.net using -f Date: Sat, 5 Jan 2008 20:59:04 -0800 From: "Crist J. Clark" To: Michael Smith Message-ID: <20080106045904.GC88922@goku.pumpky.net> References: <20080104215626.GA88922@goku.pumpky.net> <0AA9B264-8935-41E9-AC26-102ED6EE253C@lurchi.franken.de> <8466A01A-B0B3-4163-BDD4-651F4AD1A08E@adhost.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8466A01A-B0B3-4163-BDD4-651F4AD1A08E@adhost.com> User-Agent: Mutt/1.4.2.3i X-URL: http://people.freebsd.org/~cjc/ Cc: Michael Tuexen , net@freebsd.org Subject: Re: Text for IPv6 Scope X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: cjclark@alum.mit.edu List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2008 05:10:10 -0000 On Sat, Jan 05, 2008 at 11:39:21AM -0800, Michael Smith wrote: > Hello All: > > I think we're crossing the streams here. The Site Local (FEC0::/10) > has been deprecated. The fe80:: is Link Local and is very much alive. Those are all of the scope values still assigned in RFC4291 which is the latest draft standard. See section 2.5.7. As for whether all of the site-local support should be removed, RFC3879, says, "...the formal deprecation allows existing usage of site-local addresses to continue until the replacement is standardized and implemented." The replacement does not yet exist. > On Jan 5, 2008, at 3:52 AM, Michael Tuexen wrote: > > >Dear all, > > > >aren't site-local IPv6 addresses depreceated (RFC 3879)? So shouldn't > >the site-local stuff be removed? > > > >Best regards > >Michael > > > >On Jan 4, 2008, at 10:56 PM, Crist J. Clark wrote: > > > >>Anyone up for adding text to the scopeid field in the ifconfig(8) > >>output for IPv6 addresses? Other OSes do. To avoid too much > >>disruption to the current format, the text is appended after the > >>currently printed hexadecimal field. > >> > >>Example: > >> > >>fxp0: flags=8843 mtu 1500 > >> options=8 > >> inet6 fe80::290:27ff:fe13:2540%fxp0 prefixlen 64 scopeid > >>0x5(site-local) > >> > >>While we're at it, update the in6.h file to include all scopes > >>in RFC4291. > >> > >>Look OK? Anyone up for applying these? > >> > >>Patches (diffs off of a not-too-current CURRENT): > >> > >>Index: sbin/ifconfig/af_inet6.c > >>=================================================================== > >>RCS file: /ncvs/freebsd/src/sbin/ifconfig/af_inet6.c,v > >>retrieving revision 1.5 > >>diff -u -r1.5 af_inet6.c > >>--- sbin/ifconfig/af_inet6.c 3 Feb 2007 03:40:33 -0000 1.5 > >>+++ sbin/ifconfig/af_inet6.c 4 Jan 2008 21:53:26 -0000 > >>@@ -290,8 +290,31 @@ > >> if ((flags6 & IN6_IFF_TEMPORARY) != 0) > >> printf("temporary "); > >> > >>- if (scopeid) > >>- printf("scopeid 0x%x ", scopeid); > >>+ if (scopeid) { > >>+ printf("scopeid 0x%x", scopeid); > >>+ switch (scopeid) { > >>+ case __IPV6_ADDR_SCOPE_INTFACELOCAL: > >>+ printf("(interface-local) "); > >>+ break; > >>+ case __IPV6_ADDR_SCOPE_LINKLOCAL: > >>+ printf("(link-local) "); > >>+ break; > >>+ case __IPV6_ADDR_SCOPE_ADMINLOCAL: > >>+ printf("(admin-local) "); > >>+ break; > >>+ case __IPV6_ADDR_SCOPE_SITELOCAL: > >>+ printf("(site-local) "); > >>+ break; > >>+ case __IPV6_ADDR_SCOPE_ORGLOCAL: > >>+ printf("(org-local) "); > >>+ break; > >>+ case __IPV6_ADDR_SCOPE_GLOBAL: > >>+ printf("(global) "); > >>+ break; > >>+ default: > >>+ putchar(' '); > >>+ } > >>+ } > >> > >> if (ip6lifetime && (lifetime.ia6t_preferred || > >>lifetime.ia6t_expire)) { > >> printf("pltime "); > >>Index: sys/netinet6/in6.h > >>=================================================================== > >>RCS file: /ncvs/freebsd/src/sys/netinet6/in6.h,v > >>retrieving revision 1.44 > >>diff -u -r1.44 in6.h > >>--- sys/netinet6/in6.h 28 Mar 2006 12:51:22 -0000 1.44 > >>+++ sys/netinet6/in6.h 4 Jan 2008 21:44:36 -0000 > >>@@ -271,6 +271,7 @@ > >>#define IPV6_ADDR_SCOPE_NODELOCAL 0x01 > >>#define IPV6_ADDR_SCOPE_INTFACELOCAL 0x01 > >>#define IPV6_ADDR_SCOPE_LINKLOCAL 0x02 > >>+#define IPV6_ADDR_SCOPE_ADMINLOCAL 0x04 > >>#define IPV6_ADDR_SCOPE_SITELOCAL 0x05 > >>#define IPV6_ADDR_SCOPE_ORGLOCAL 0x08 /* just used in this file */ > >>#define IPV6_ADDR_SCOPE_GLOBAL 0x0e > >>@@ -278,6 +279,7 @@ > >>#define __IPV6_ADDR_SCOPE_NODELOCAL 0x01 > >>#define __IPV6_ADDR_SCOPE_INTFACELOCAL 0x01 > >>#define __IPV6_ADDR_SCOPE_LINKLOCAL 0x02 > >>+#define __IPV6_ADDR_SCOPE_ADMINLOCAL 0x04 > >>#define __IPV6_ADDR_SCOPE_SITELOCAL 0x05 > >>#define __IPV6_ADDR_SCOPE_ORGLOCAL 0x08 /* just used in this file */ > >>#define __IPV6_ADDR_SCOPE_GLOBAL 0x0e > >>-- > >>Crist J. Clark | cjclark@alum.mit.edu > >>_______________________________________________ > >>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" -- Crist J. Clark | cjclark@alum.mit.edu From owner-freebsd-net@FreeBSD.ORG Sun Jan 6 11:27:32 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E1DB16A46E for ; Sun, 6 Jan 2008 11:27:32 +0000 (UTC) (envelope-from freebsd@levsha.org.ua) Received: from expo.ukrweb.net (expo.ukrweb.net [193.125.78.116]) by mx1.freebsd.org (Postfix) with ESMTP id EE3E213C448 for ; Sun, 6 Jan 2008 11:27:31 +0000 (UTC) (envelope-from freebsd@levsha.org.ua) Received: from levsha by expo.ukrweb.net with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JBTYP-000I6S-M8; Sun, 06 Jan 2008 13:20:33 +0200 Date: Sun, 6 Jan 2008 13:20:33 +0200 From: Mykola Dzham To: Julian Elischer Message-ID: <20080106112033.GA40991@expo.ukrweb.net> References: <4772F123.5030303@elischer.org> <477416CC.4090906@elischer.org> <477D2EF3.2060909@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <477D2EF3.2060909@elischer.org> X-Operating-System: FreeBSD/5.4-RELEASE-p6 (i386) User-Agent: Mutt/1.5.6i Cc: Qing Li , FreeBSD Net , arch@freebsd.org, Ivo Vachkov , Robert Watson , Vadim Goncharov Subject: Re: resend: multiple routing table roadmap (format fix) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2008 11:27:32 -0000 Julian Elischer wrote: > > setfib 3 /bin/sh > > now by default everythign you do uses table 3. > or even > > setfib 3 jail {blah} > > and all the procs in the jail use table 3. You also need to do > setfib 3 jexec xxx > for extra processes you add to the jail afterwards. Is it possible to deny setfib after setfib N /bin/sh ? Or call setfib from jail? If yes this can be usable for restriction jail on some different fib -- Mykola Dzham, LEFT-(UANIC|RIPE) JID: levsha@jabber.net.ua From owner-freebsd-net@FreeBSD.ORG Sun Jan 6 13:47:26 2008 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ECAA016A46E; Sun, 6 Jan 2008 13:47:25 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id B5B1F13C474; Sun, 6 Jan 2008 13:47:25 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 5C1804B2B0; Sun, 6 Jan 2008 08:47:25 -0500 (EST) Date: Sun, 6 Jan 2008 13:47:24 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: arch@FreeBSD.org Message-ID: <20080106124517.G105@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: kmacy@FreeBSD.org, net@FreeBSD.org Subject: Network device driver KPI/ABI and TOE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2008 13:47:26 -0000 Dear all, Last month, Kip Macy committed support for TCP offload to the FreeBSD CVS repository for the Chelsio 10gbps device driver. We've had interest from other vendors in supporting TOE on FreeBSD, although it remains unclear as yet which will end up supporting it. This e-mail is about how we want to treat the TOE interface with respect to third party device driver support, and more specifically to propose that we not consider the TOE interface to be part of our stable network device driver KPI/ABI once it appears in a RELENG_X branch. The background: in the last few FreeBSD versions (late 5.x, 6.x, 7.x), we've attempted to offer network and storage device driver authors a stable KPI and ABI across minor FreeBSD releases. The goal of this has been to allow authors to produce a device driver module for a .0 release, and then have it continue to function for .1, .2, and so on. We've not attempted to formalize the details of this for network device drivers, but implicitly this includes interface stability for things like mbuf and memory management routines, the ifnet interface, locking interfaces and data structures, newbus, busdma, and so on. If we had to, we would break the ABI in order to fix critical bugs (etc), but we try hard to avoid it in order to improve interface stability, and, in general, we choose not to MFC features that would break existing device drivers. TOE comes with a series of defined interfaces in toedev.h (documentation forthcoming) and tcp_offload.h (documentation now in comments). However, TOE implementations must also interact directly with the TCP and other stack internals, including directly accessing socket buffers, routing, the inpcb and tcpcb data structures, TCP and inpcb locking protocols, and so on. This happens for two reasons: - First, TOE needs to interact with the contents of sockets and TCP in order to implement the offload (i.e., extracting data from socket buffers to transmit it, putting data into socket buffers on receive, accessing TCP connection properties such as socket options, address bindings, listen state, etc). - Second, TOE hardware implementations often don't implement all of TCP: they may implement the steady state but not TCP TIMEWAIT or connection setup, for example. To get a sense of the level of intimacy of one such driver, it's well worth perusing src/sys/dev/cxgb/ulp/tom in HEAD. This is not a criticism, but I do want people to be aware of what's there before getting involved in this discussion: TOE takes to a whole new level the mantra that layering is good for protocol design, but not good for implementation performance, and spans pretty much all layers of the network stack in its scope. There are serious ABI implications to this approach, as historically we've made significant changes to the TCP and socket buffer internals during -stable branches, such as optimizing performance, adding new TCP features, etc. There's a fairly aggressive list of forthcoming TCP features for 8.0 with MFC plans for several of them, such as congestion control selection and multiple routing tables. I've not attempted to analyze these past or proposed changes in detail to determine how disruptive they would be to a TOE implementation, but my guess is that they might well break TOE drivers, especially historic ones, had TOE been supported at the time. My proposal, and this is really a proposal to drive discussion as much as a proposal for a policy, is that the internal TCP data structures exported via the TOE interfaces and accessed by TOE device drivers *not* be considered ABI/KPI-stable in -STABLE branches. While I think we shouldn't intentionally change them to break TOE, it's unrealistic to expect that these network stack internals won't change as part of normal maintenance and feature development that take place in -STABLE branches. For those who aren't involved in those day-to-day internals, a comparable situation might be if a CAM SCSI storage driver was dependent not only on there being no changes made to the on-disk layout of UFS (even backwards compatible ones), but also the in-memory data structures of soft updates. Any significant changes to soft updates internals would break such device drivers due to a requirement for forward compatibility. In some ways this isn't a perfect comparison, as soft updates isn't under active development, but from a layering and abstraction perspective, it's quite similar. We don't yet ship TOE in a -STABLE branch, but I believe Kip hopes to MFC TOE support, and with other device driver vendors starting to take a look, I think we want out thoughts on the table regarding this matter. I presume that we'll see the TOE interfaces continue to evolve over the next 6-18 months, and we should make sure that we know whether or not third party device driver authors can expect ABI/KPI stability before, rather than after, it hits a -STABLE branch. On a similar note, these necessary changes to network stack internals will result in modifications to in-tree device drivers, so device driver authors who implement TOE should expect to see the TOE parts of their drivers being significantly modified as development occurs on those other parts of the stack. There's also the opportunity to think about whether it's possible to harden things in such a ways as to not give up our flexibility to keep maintaining and improving TCP (and other related subsystems), yet improving the quality of life for a third party TOE driver maintainer. For example, might we provide accessor routines for certain data structures, or attempt to structure things to hide more of TCP locking from a TOE implementation? Should we suggest that non-native TOE implementations rely less on our TCP code and provide there own where the hardware doesn't provide a complete implementation, in order to avoid building dependency on things that we know will change? Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-net@FreeBSD.ORG Sun Jan 6 14:30:04 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1739D16A419; Sun, 6 Jan 2008 14:30:04 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id DB53413C478; Sun, 6 Jan 2008 14:30:03 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 4EF1983258; Sun, 6 Jan 2008 09:30:03 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Sun, 06 Jan 2008 09:30:03 -0500 X-Sasl-enc: nhl4+Qhx1Sp1F8iKOI4jppIjlJmSUMq8Ot3NP8CjVKq2 1199629802 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id BE3D523475; Sun, 6 Jan 2008 09:30:01 -0500 (EST) Message-ID: <4780E5E7.2070202@FreeBSD.org> Date: Sun, 06 Jan 2008 14:29:59 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.6 (X11/20070928) MIME-Version: 1.0 To: Vadim Goncharov References: <4772F123.5030303@elischer.org> <477416CC.4090906@elischer.org> <477D2EF3.2060909@elischer.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Qing Li , FreeBSD Net , arch@freebsd.org, Ivo Vachkov , Robert Watson , Julian Elischer Subject: Re: resend: multiple routing table roadmap (format fix) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2008 14:30:04 -0000 Vadim Goncharov wrote: > > Is multicast and multipath routing the same? No. They are currently orthogonal. However it makes sense to merge the multicast and unicast forwarding code as currently MROUTING is limited to a fan-out of 32 next-hops only. In multicast, next-hops are normally just interfaces. Also the IETF MANET ad-hoc IP is going to need hooks there; multicast in MANET needs to address its next-hops by their unicast address, and encapsulate the traffic with a header. This is not true link layer multicast -- although it might use link layer multicast to leverage the hash filters in 802.11 MACs. As regards getting ARP out of forwarding tables, this should have happened a long time ago... BMS From owner-freebsd-net@FreeBSD.ORG Sun Jan 6 14:31:48 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F018616A420; Sun, 6 Jan 2008 14:31:48 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id BFFFA13C467; Sun, 6 Jan 2008 14:31:48 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 2611983053; Sun, 6 Jan 2008 09:31:48 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Sun, 06 Jan 2008 09:31:48 -0500 X-Sasl-enc: hIZXm1v/XEp5jk+bgdWLzB+SqxKxPZ/jOLMCDbmrXXRi 1199629907 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 06EA110BF0; Sun, 6 Jan 2008 09:31:46 -0500 (EST) Message-ID: <4780E652.5040804@FreeBSD.org> Date: Sun, 06 Jan 2008 14:31:46 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.6 (X11/20070928) MIME-Version: 1.0 To: Julian Elischer References: <4772F123.5030303@elischer.org> <477416CC.4090906@elischer.org> <477D2EF3.2060909@elischer.org> <47802137.8020701@elischer.org> In-Reply-To: <47802137.8020701@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Qing Li , FreeBSD Net , Vadim Goncharov , arch@freebsd.org, Ivo Vachkov , Robert Watson Subject: Re: resend: multiple routing table roadmap (format fix) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2008 14:31:49 -0000 Julian Elischer wrote: >> >> OK, but we should think about it in the future. In theory, routing >> socket's messages are easily extendable with FIB number in uint16_t, >> as message keeps it's length... > > I will do that with the advice of people who know that protocol better > than I do. I'm afraid Linux is still ahead of the game here. They adopted a tag-length-value protocol called NETLINK which solves many of the problems inherent in PF_ROUTE. It even has an RFC. BMS From owner-freebsd-net@FreeBSD.ORG Sun Jan 6 17:50:05 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9538D16A417 for ; Sun, 6 Jan 2008 17:50:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 92EFF13C45B for ; Sun, 6 Jan 2008 17:50:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m06Ho5nb010168 for ; Sun, 6 Jan 2008 17:50:05 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m06Ho5bX010167; Sun, 6 Jan 2008 17:50:05 GMT (envelope-from gnats) Date: Sun, 6 Jan 2008 17:50:05 GMT Message-Id: <200801061750.m06Ho5bX010167@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Bob Van Zant Cc: Subject: Re: kern/116837: ifconfig tunX destroy: panic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bob Van Zant List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2008 17:50:05 -0000 The following reply was made to PR kern/116837; it has been noted by GNATS. From: Bob Van Zant To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/116837: ifconfig tunX destroy: panic Date: Sun, 6 Jan 2008 22:46:09 +0530 My FreeBSD 7.0-PRERELEASE box has been running into this problem a lot recently when I reset my ppp connection to counteract the effects of having a very poor ISP. I would like to fix this bug. Is there anyone that can help me identify what the proper behavior is? In my case the repro is something along the lines of: - Create ppp connection (tun0) - Create six-to-four connection (stf0) - The ppp connection gets wedged - /etc/rc.d/ppp stop - ifconfig tun0 destroy - kernel panic My hunch is that the stf0 interface being "on top" of tun0 is causing the problem. I've changed the script, maybe the panic will stop happening. But what should the behavior be? Should the if_tun code make an attempt to clean up whatever it can and then just destroy the interface like requested? Or should it return some sort of error and the ifconfig request to destroy the interface fails? The if_tap code appears to have the same assert in its destroy function and we may want to fix that as well. I tend to get a few spare hours during any given week to play with these sorts of things and I'd like to be able to help out with this one. Any sort of direction folks can give in working towards a solution will be appreciated. -Bob From owner-freebsd-net@FreeBSD.ORG Sun Jan 6 17:56:46 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8AB0416A468 for ; Sun, 6 Jan 2008 17:56:46 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outG.internet-mail-service.net (outG.internet-mail-service.net [216.240.47.230]) by mx1.freebsd.org (Postfix) with ESMTP id 7895A13C448 for ; Sun, 6 Jan 2008 17:56:46 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Sun, 06 Jan 2008 09:56:45 -0800 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 17711126E36; Sun, 6 Jan 2008 09:56:45 -0800 (PST) Message-ID: <4781166D.2010108@elischer.org> Date: Sun, 06 Jan 2008 09:57:01 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Mykola Dzham References: <4772F123.5030303@elischer.org> <477416CC.4090906@elischer.org> <477D2EF3.2060909@elischer.org> <20080106112033.GA40991@expo.ukrweb.net> In-Reply-To: <20080106112033.GA40991@expo.ukrweb.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Qing Li , FreeBSD Net , arch@freebsd.org, Ivo Vachkov , Robert Watson , Vadim Goncharov Subject: Re: resend: multiple routing table roadmap (format fix) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2008 17:56:46 -0000 Mykola Dzham wrote: > Julian Elischer wrote: >> setfib 3 /bin/sh >> >> now by default everythign you do uses table 3. >> or even >> >> setfib 3 jail {blah} >> >> and all the procs in the jail use table 3. You also need to do >> setfib 3 jexec xxx >> for extra processes you add to the jail afterwards. > > Is it possible to deny setfib after setfib N /bin/sh ? Or call setfib > from jail? If yes this can be usable for restriction jail on some > different fib > I hadn't considered that.. though possibly what you want is vimage(). From owner-freebsd-net@FreeBSD.ORG Sun Jan 6 18:07:49 2008 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4DB116A468 for ; Sun, 6 Jan 2008 18:07:49 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outD.internet-mail-service.net (outD.internet-mail-service.net [216.240.47.227]) by mx1.freebsd.org (Postfix) with ESMTP id CA9AB13C457 for ; Sun, 6 Jan 2008 18:07:49 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Sun, 06 Jan 2008 10:07:48 -0800 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 39DA7126E32; Sun, 6 Jan 2008 10:07:48 -0800 (PST) Message-ID: <47811904.4060300@elischer.org> Date: Sun, 06 Jan 2008 10:08:04 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Robert Watson References: <20080106124517.G105@fledge.watson.org> In-Reply-To: <20080106124517.G105@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@FreeBSD.org, kmacy@FreeBSD.org, net@FreeBSD.org Subject: Re: Network device driver KPI/ABI and TOE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2008 18:07:49 -0000 Robert Watson wrote: > > There's also the opportunity to think about whether it's possible to > harden things in such a ways as to not give up our flexibility to keep > maintaining and improving TCP (and other related subsystems), yet > improving the quality of life for a third party TOE driver maintainer. > For example, might we provide accessor routines for certain data > structures, or attempt to structure things to hide more of TCP locking > from a TOE implementation? Should we suggest that non-native TOE > implementations rely less on our TCP code and provide there own where > the hardware doesn't provide a complete implementation, in order to > avoid building dependency on things that we know will change? I think the answer is to do as you suggest, and provide some sort of interface with access methods so that TOE doesn't see so much of the internal side of the networking, but has methods (no matter how specialised) to do these things. Unfortunately I am not sure that can be done in all situations.. for example I'm not sure you could isolate a change in the mbuf packet header. (That is a whole different discussion.. I think we may need to give mbufs a workover for the 21st century but I digress...) I'll read this again when I have more time.. I'm of course "interested" due to various bits of work I have going.. > > Robert N M Watson > Computer Laboratory > University of Cambridge > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Sun Jan 6 18:09:52 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84ADF16A47E for ; Sun, 6 Jan 2008 18:09:52 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outF.internet-mail-service.net (outF.internet-mail-service.net [216.240.47.229]) by mx1.freebsd.org (Postfix) with ESMTP id 71F2013C45D for ; Sun, 6 Jan 2008 18:09:52 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Sun, 06 Jan 2008 10:09:51 -0800 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id C6FA5126E1D; Sun, 6 Jan 2008 10:09:50 -0800 (PST) Message-ID: <4781197F.1000105@elischer.org> Date: Sun, 06 Jan 2008 10:10:07 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: "Bruce M. Simpson" References: <4772F123.5030303@elischer.org> <477416CC.4090906@elischer.org> <477D2EF3.2060909@elischer.org> <4780E5E7.2070202@FreeBSD.org> In-Reply-To: <4780E5E7.2070202@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Qing Li , FreeBSD Net , Vadim Goncharov , arch@freebsd.org, Ivo Vachkov , Robert Watson Subject: Re: resend: multiple routing table roadmap (format fix) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2008 18:09:52 -0000 Bruce M. Simpson wrote: > Vadim Goncharov wrote: >> >> Is multicast and multipath routing the same? > > No. They are currently orthogonal. > > However it makes sense to merge the multicast and unicast forwarding > code as currently MROUTING is limited to a fan-out of 32 next-hops only. > In multicast, next-hops are normally just interfaces. > > Also the IETF MANET ad-hoc IP is going to need hooks there; multicast in > MANET needs to address its next-hops by their unicast address, and > encapsulate the traffic with a header. This is not true link layer > multicast -- although it might use link layer multicast to leverage the > hash filters in 802.11 MACs. > > As regards getting ARP out of forwarding tables, this should have > happened a long time ago... I'm not 100 % convinced of this... I was, but I think there may still be a place for a cached arp pointer in hte next hop route to the arp entry for that next hop. I DO however thing that the arp stuff should nto be accessing its data via the routing table. > > BMS From owner-freebsd-net@FreeBSD.ORG Sun Jan 6 18:37:20 2008 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A486B16A418; Sun, 6 Jan 2008 18:37:20 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 88EF013C442; Sun, 6 Jan 2008 18:37:20 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 0455B48E35; Sun, 6 Jan 2008 13:37:20 -0500 (EST) Date: Sun, 6 Jan 2008 18:37:19 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Julian Elischer In-Reply-To: <47811904.4060300@elischer.org> Message-ID: <20080106182340.K105@fledge.watson.org> References: <20080106124517.G105@fledge.watson.org> <47811904.4060300@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@FreeBSD.org, kmacy@FreeBSD.org, net@FreeBSD.org Subject: Re: Network device driver KPI/ABI and TOE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2008 18:37:20 -0000 On Sun, 6 Jan 2008, Julian Elischer wrote: >> There's also the opportunity to think about whether it's possible to harden >> things in such a ways as to not give up our flexibility to keep maintaining >> and improving TCP (and other related subsystems), yet improving the quality >> of life for a third party TOE driver maintainer. For example, might we >> provide accessor routines for certain data structures, or attempt to >> structure things to hide more of TCP locking from a TOE implementation? >> Should we suggest that non-native TOE implementations rely less on our TCP >> code and provide there own where the hardware doesn't provide a complete >> implementation, in order to avoid building dependency on things that we >> know will change? > > I think the answer is to do as you suggest, and provide some sort of > interface with access methods so that TOE doesn't see so much of the > internal side of the networking, but has methods (no matter how specialised) > to do these things. > > Unfortunately I am not sure that can be done in all situations.. for example > I'm not sure you could isolate a change in the mbuf packet header. (That is > a whole different discussion.. I think we may need to give mbufs a workover > for the 21st century but I digress...) > > I'll read this again when I have more time.. I'm of course "interested" due > to various bits of work I have going.. Disruptive mbuf packet header layout changes during the lifetime of a -STABLE branch are already precluded by the ABI/KPI policy, since knowledge of the packet header layout is compiled into all network device drivers. What I'm more concerned about is the new exposure of internal data structures and algorithms, and a resulting freeze of those data structures and algorithms if we were to apply our current ABI/PI policy to the TOE interfaces. I don't think we should apply it there for the forseeable future, and we should make sure there's no confusion for device vendors or end-users who may have come to rely on the stability of ifnet and related interfaces and hence assume it also applies to the new TOE interfaces. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-net@FreeBSD.ORG Sun Jan 6 20:01:07 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C09BD16A421 for ; Sun, 6 Jan 2008 20:01:07 +0000 (UTC) (envelope-from peter@alastria.net) Received: from nebula.thdo.uk.alastria.net (unknown [IPv6:2001:ba8:0:1f0::5]) by mx1.freebsd.org (Postfix) with ESMTP id 7417A13C459 for ; Sun, 6 Jan 2008 20:01:07 +0000 (UTC) (envelope-from peter@alastria.net) Received: from [10.10.4.10] (dragon.lancs.uk.alastria.net [88.96.139.34]) (authenticated bits=0) by nebula.thdo.uk.alastria.net (8.13.3/8.13.3) with ESMTP id m06K1JHm015490 for ; Sun, 6 Jan 2008 20:01:19 GMT (envelope-from peter@alastria.net) Message-ID: <4781337B.40104@alastria.net> Date: Sun, 06 Jan 2008 20:00:59 +0000 From: Peter Wood Organization: Alastria Networks Limited User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Flag: NO X-Virus-Status: No X-Spam-Score: 0.137 () RCVD_IN_SORBS_DUL X-Spam-Ultra-Flag: NO X-Spam-Low-Flag: NO X-Spam-Flag: NO X-Spam-High-Flag: NO X-Scanned-By: MIMEDefang 2.51 on 212.13.198.8 Subject: Implementation of Sampling for BPF X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2008 20:01:07 -0000 Hey All, I piped up a couple of weeks before Christmas regarding a need to control or at least reliably predict which packets a system would drop if too many packets where being received by the kernel destined for a BPF program. My particular example here is a copy of Snort monitoring a mirror of two 1000mbs lines, with data rates averaging about 900mbs now. As you can imagin with a reasonable Snort ruleset the kernel is being forced to drop packets before Snort can process all data sent to it, it is the uncertainly of a fair sample (or lack of) that I'm worried about. So today I finally sat down and looked at implementing this on a copy of the source tree for RELENG_7 from cvs (as this would be the OS we would run, although I'll happily rework it for CURRENT once complete). I've had an interesting experience as this has been my first time modifying the networking side of the BSD kernel. I initially sat down to implement a "capture 1 in x" model, and have managed (with what seems like a duct tape special) to implement this basic functionality by altering the common macro's for receiving and sending data BPF_?TAP? and ETHER_BPF_MTAP. One issue I have come across is that due to the order of execution of ifp->if_data.ifi_ipacket/ifp->if_data.ifi_opacket and the various BPF macros for packets that cause a response, providing the reply is quick enough that too will be captured for BPF. For example: Incoming (ICMP Request) ----------------------- ifp->if_data.ifi_ipacket++; ETHER_BFP_MTAP(); Outgoing (ICMP Responce) ------------------------ BFP_MTAP(); ifp->if_data.ifi_opacket++; So instead I am now looking at reimplementing the concept with the sampling method I had originally wanted which is "ever x packets capture y packets up until z packets in a second". It is now this part I'm looking for feedback from, probably from the more experiences BSD network hackers. I haven't done a complete survey of the interface drivers, nor have I looked at the none NIC interfaces, however I'm unsure that I should trust that the order of execution for incoming and outgoing packets to be the same. Instead I'm considering looking at implementing the sampling in bpf_?tap? in bpf.c just after the BPF interface lock is acquired. From my usage point of view I would like the sampling rules to affect all bpf listeners the same (i.e. they receive the same packets). In my case this is more for debugging purposes so that I can see what packets Snort is receiving without shutting it down and putting it into debug. I believe I would need to maintain the following new information in the bpf_if structure, probably in it's own structure to keep it neat: struct bpf_sample { u_int skip; /* Number of packets to skip before a run */ u_int run; /* Number of packets to run and capture */ int maxpps; /* Maximum number of packets per second */ u_int current; /* Number of packets seen in skip+run */ /* Making use of ppsratecheck() from kern_time.c */ int curpps; /* Current number of packets per second */ struct timeval lasttime; /* Last "time" (actually ticks in tv->sec) */ }; My first question is would bpf_if be the correct place for this information? I looked at ifnet, however as this data only affects bpf it makes a tad more sense for it to go into bpf_if. From the code I have read, bpfif is initialized from bpfattach2, which is in turn called by ether_ifattach via bpfattach, and should be available as soon as the interface is added to the kernels interface list. Secondly because this is interface wide, and I'm unaware of any other control application for BPF I'd look at extending ifconfig with some new directives to control this. Perhaps something like: ifconfig le0 SAMPLESKIP 1000 SAMPLERUN 100 SAMPLEMAX 100000 ifconfig le0 SAMPLE } Already have these two using a new flag of IFF_SAMPLE, ifconfig le0 -SAMPLE } although I can understand objection to new flags. From what I've seen this would require the implementation of several new ioctl's which would be received by ifhwioctl in if.c. However if it was stored in bpfif, that would require obtaining the lock from if.c which currently has no files from BPF included. What's the best way to address this? Leave the data in ifnet? But if it's in ifnet do I need to lock the ifnet for each packet in BPF? I think to be honest that's all the specific questions I have, otherwise does it look like I'm headed in the right direction? I appreciated someone more experienced could probably just knock this up in a couple of minutes, but I'm willing/wanting to learn. Thanks, P. -- Peter Wood From owner-freebsd-net@FreeBSD.ORG Sun Jan 6 21:03:18 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4CD816A419; Sun, 6 Jan 2008 21:03:18 +0000 (UTC) (envelope-from vadim_nuclight@mail.ru) Received: from mx40.mail.ru (mx40.mail.ru [194.67.23.36]) by mx1.freebsd.org (Postfix) with ESMTP id 7682113C458; Sun, 6 Jan 2008 21:03:18 +0000 (UTC) (envelope-from vadim_nuclight@mail.ru) Received: from [78.140.2.250] (port=25243 helo=nuclight.avtf.net) by mx40.mail.ru with esmtp id 1JBceK-000PPB-00; Mon, 07 Jan 2008 00:03:16 +0300 Date: Mon, 07 Jan 2008 03:03:11 +0600 To: "Julian Elischer" , "Bruce M. Simpson" References: <4772F123.5030303@elischer.org> <477416CC.4090906@elischer.org> <477D2EF3.2060909@elischer.org> <4780E5E7.2070202@FreeBSD.org> <4781197F.1000105@elischer.org> From: "Vadim Goncharov" Organization: AVTF TPU Hostel Content-Type: text/plain; format=flowed; delsp=yes; charset=koi8-r MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <4781197F.1000105@elischer.org> User-Agent: Opera M2/7.54 (Win32, build 3865) Cc: arch@freebsd.org, Qing Li , Ivo Vachkov , Robert Watson , FreeBSD Net Subject: Re: resend: multiple routing table roadmap (format fix) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2008 21:03:18 -0000 07.01.08 @ 00:10 Julian Elischer wrote: >>> Is multicast and multipath routing the same? >> No. They are currently orthogonal. >> However it makes sense to merge the multicast and unicast forwarding >> code as currently MROUTING is limited to a fan-out of 32 next-hops >> only. In multicast, next-hops are normally just interfaces. >> Also the IETF MANET ad-hoc IP is going to need hooks there; multicast >> in MANET needs to address its next-hops by their unicast address, and >> encapsulate the traffic with a header. This is not true link layer >> multicast -- although it might use link layer multicast to leverage the >> hash filters in 802.11 MACs. >> As regards getting ARP out of forwarding tables, this should have >> happened a long time ago... > > I'm not 100 % convinced of this... > I was, but I think there may still be a place for a cached arp pointer > in hte next hop route to the arp entry for that next hop. > I DO however thing that the arp stuff should nto be accessing its > data via the routing table. Surely, routing table should contain a cached pointer to an entry in L2 table (ARP in case of Ethernet), to not do double lookups. But still separate those tables... -- WBR, Vadim Goncharov From owner-freebsd-net@FreeBSD.ORG Sun Jan 6 21:25:10 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 24ECE16A41B for ; Sun, 6 Jan 2008 21:25:10 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by mx1.freebsd.org (Postfix) with ESMTP id AC85E13C468 for ; Sun, 6 Jan 2008 21:25:09 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by fg-out-1718.google.com with SMTP id 16so4885620fgg.35 for ; Sun, 06 Jan 2008 13:25:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=UjHAisz+SN1VuzeWsiMWnN5ZkDfyUdMj/Ivt6b53I/U=; b=NsRUvMmfcK5MNcaY5GQf1wNIYc7TJzAcAxqaC1o++QLJ5gSWg1NyRKMkexFE2JbIzMnouhmq0LEARNhY3Hou43MVh0/6nUO6R+2ch7BWG5OK6Xm5LDOEErkJ3PzwmK453htwHNZQn9eek2h3QxUAlNG7SAl5NuXRO/AY5BYudGU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=XGCYEpiM+KHSBeOC8Xgo3qJI/nSS3k8LjbQr1fLTWBfHTea83WN0qn0AFgg8Rid3Inxn7ggqoQlgSEZzgrGYZt+czA39B8ZPNzjqMcMYkbI209NtuM1p2PyfJVeIp4jz6a+Cdkm9YPYaR/yFwxdc7oJiS0zYkwnYWIwpBNx8FJ8= Received: by 10.86.79.19 with SMTP id c19mr19372527fgb.31.1199653010854; Sun, 06 Jan 2008 12:56:50 -0800 (PST) Received: by 10.86.98.15 with HTTP; Sun, 6 Jan 2008 12:56:50 -0800 (PST) Message-ID: <2a41acea0801061256j867053dq69b46664e0283b3e@mail.gmail.com> Date: Sun, 6 Jan 2008 12:56:50 -0800 From: "Jack Vogel" To: "Robert Watson" In-Reply-To: <20080106124517.G105@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080106124517.G105@fledge.watson.org> Cc: arch@freebsd.org, kmacy@freebsd.org, net@freebsd.org Subject: Re: Network device driver KPI/ABI and TOE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2008 21:25:10 -0000 On Jan 6, 2008 5:47 AM, Robert Watson wrote: ... > My proposal, and this is really a proposal to drive discussion as much as a > proposal for a policy, is that the internal TCP data structures exported via > the TOE interfaces and accessed by TOE device drivers *not* be considered > ABI/KPI-stable in -STABLE branches. While I think we shouldn't intentionally > change them to break TOE, it's unrealistic to expect that these network stack > internals won't change as part of normal maintenance and feature development > that take place in -STABLE branches. > > For those who aren't involved in those day-to-day internals, a comparable > situation might be if a CAM SCSI storage driver was dependent not only on > there being no changes made to the on-disk layout of UFS (even backwards > compatible ones), but also the in-memory data structures of soft updates. Any > significant changes to soft updates internals would break such device drivers > due to a requirement for forward compatibility. In some ways this isn't a > perfect comparison, as soft updates isn't under active development, but from a > layering and abstraction perspective, it's quite similar. > > We don't yet ship TOE in a -STABLE branch, but I believe Kip hopes to MFC TOE > support, and with other device driver vendors starting to take a look, I think > we want out thoughts on the table regarding this matter. I presume that we'll > see the TOE interfaces continue to evolve over the next 6-18 months, and we > should make sure that we know whether or not third party device driver authors > can expect ABI/KPI stability before, rather than after, it hits a -STABLE > branch. On a similar note, these necessary changes to network stack internals > will result in modifications to in-tree device drivers, so device driver > authors who implement TOE should expect to see the TOE parts of their drivers > being significantly modified as development occurs on those other parts of the > stack. > > There's also the opportunity to think about whether it's possible to harden > things in such a ways as to not give up our flexibility to keep maintaining > and improving TCP (and other related subsystems), yet improving the quality of > life for a third party TOE driver maintainer. For example, might we provide > accessor routines for certain data structures, or attempt to structure things > to hide more of TCP locking from a TOE implementation? Should we suggest that > non-native TOE implementations rely less on our TCP code and provide there own > where the hardware doesn't provide a complete implementation, in order to > avoid building dependency on things that we know will change? I agree Robert, I have hit minor KPI changes during the 6.X evolution and found them annoying. On the other hand, I know what its like when a company has hardware and wants support for it :) Is it perhaps a possible compromise to put in support but leave it defined off by default? Happy New Year BTW :) Jack From owner-freebsd-net@FreeBSD.ORG Sun Jan 6 21:27:04 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9CCD516A46C for ; Sun, 6 Jan 2008 21:27:04 +0000 (UTC) (envelope-from vadim_nuclight@mail.ru) Received: from mx7.mail.ru (mx7.mail.ru [194.67.23.27]) by mx1.freebsd.org (Postfix) with ESMTP id 5EAA013C47E for ; Sun, 6 Jan 2008 21:27:04 +0000 (UTC) (envelope-from vadim_nuclight@mail.ru) Received: from [78.140.2.250] (port=53202 helo=nuclight.avtf.net) by mx7.mail.ru with esmtp id 1JBd1K-000EnW-00 for freebsd-net@freebsd.org; Mon, 07 Jan 2008 00:27:02 +0300 Date: Mon, 07 Jan 2008 03:27:01 +0600 To: freebsd-net@freebsd.org References: <4781337B.40104@alastria.net> From: "Vadim Goncharov" Organization: AVTF TPU Hostel Content-Type: text/plain; format=flowed; delsp=yes; charset=koi8-r MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <4781337B.40104@alastria.net> User-Agent: Opera M2/7.54 (Win32, build 3865) Subject: Re: Implementation of Sampling for BPF X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2008 21:27:04 -0000 07.01.08 @ 02:00 Peter Wood wrote: > Hey All, > > I piped up a couple of weeks before Christmas regarding a need to > control or at > least reliably predict which packets a system would drop if too many > packets > where being received by the kernel destined for a BPF program. My > particular > example here is a copy of Snort monitoring a mirror of two 1000mbs > lines, with > data rates averaging about 900mbs now. > > As you can imagin with a reasonable Snort ruleset the kernel is being > forced to > drop packets before Snort can process all data sent to it, it is the > uncertainly of a fair sample (or lack of) that I'm worried about. [...] I don't think that modifying bpf.c is good solution, as userland is not the only consumer of BPF, think, for example, about ng_bpf. Moreover, what is the purpose of sampling, after all? BPF was never intended to be reliable every-packet solution. If you are monitoring in userland, Snort of course will not have enough time to process all of your data, so why not simply put at least two machines in parallel, one for each mirrored line? -- WBR, Vadim Goncharov From owner-freebsd-net@FreeBSD.ORG Sun Jan 6 21:41:04 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD1F816A46C for ; Sun, 6 Jan 2008 21:41:04 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 3384313C45B for ; Sun, 6 Jan 2008 21:41:03 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 84605 invoked from network); 6 Jan 2008 21:05:35 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 6 Jan 2008 21:05:35 -0000 Message-ID: <47814AF0.9070509@freebsd.org> Date: Sun, 06 Jan 2008 22:41:04 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Vadim Goncharov References: <4772F123.5030303@elischer.org> <477416CC.4090906@elischer.org> <477D2EF3.2060909@elischer.org> <4780E5E7.2070202@FreeBSD.org> <4781197F.1000105@elischer.org> In-Reply-To: Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: Qing Li , FreeBSD Net , arch@freebsd.org, Ivo Vachkov , Robert Watson , Julian Elischer , "Bruce M. Simpson" Subject: Re: resend: multiple routing table roadmap (format fix) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2008 21:41:04 -0000 Vadim Goncharov wrote: > 07.01.08 @ 00:10 Julian Elischer wrote: > > >>>> Is multicast and multipath routing the same? >>> No. They are currently orthogonal. >>> However it makes sense to merge the multicast and unicast forwarding >>> code as currently MROUTING is limited to a fan-out of 32 next-hops >>> only. In multicast, next-hops are normally just interfaces. >>> Also the IETF MANET ad-hoc IP is going to need hooks there; >>> multicast in MANET needs to address its next-hops by their unicast >>> address, and encapsulate the traffic with a header. This is not true >>> link layer multicast -- although it might use link layer multicast to >>> leverage the hash filters in 802.11 MACs. >>> As regards getting ARP out of forwarding tables, this should have >>> happened a long time ago... >> >> I'm not 100 % convinced of this... >> I was, but I think there may still be a place for a cached arp pointer >> in hte next hop route to the arp entry for that next hop. >> I DO however thing that the arp stuff should nto be accessing its >> data via the routing table. > > Surely, routing table should contain a cached pointer to an entry in L2 > table (ARP in case of Ethernet), to not do double lookups. But still > separate those tables... Locking hell over again. How do you remove an ARP entry without doing a full walk over the entire routing table (some 250K entries for the DFZ)? Make it rmlocks and be done with it. -- Andre From owner-freebsd-net@FreeBSD.ORG Sun Jan 6 22:01:55 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70AC216A41A for ; Sun, 6 Jan 2008 22:01:55 +0000 (UTC) (envelope-from peter@alastria.net) Received: from nebula.thdo.uk.alastria.net (unknown [IPv6:2001:ba8:0:1f0::5]) by mx1.freebsd.org (Postfix) with ESMTP id 669A013C457 for ; Sun, 6 Jan 2008 22:01:54 +0000 (UTC) (envelope-from peter@alastria.net) Received: from [10.10.4.10] (dragon.lancs.uk.alastria.net [88.96.139.34]) (authenticated bits=0) by nebula.thdo.uk.alastria.net (8.13.3/8.13.3) with ESMTP id m06M24G2023325 for ; Sun, 6 Jan 2008 22:02:04 GMT (envelope-from peter@alastria.net) Message-ID: <47814FC7.6080106@alastria.net> Date: Sun, 06 Jan 2008 22:01:43 +0000 From: Peter Wood Organization: Alastria Networks Limited User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <4781337B.40104@alastria.net> In-Reply-To: Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Flag: NO X-Virus-Status: No X-Spam-Score: 0.137 () RCVD_IN_SORBS_DUL X-Spam-Ultra-Flag: NO X-Spam-Low-Flag: NO X-Spam-Flag: NO X-Spam-High-Flag: NO X-Scanned-By: MIMEDefang 2.51 on 212.13.198.8 Subject: Re: Implementation of Sampling for BPF X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2008 22:01:55 -0000 Evening, > I don't think that modifying bpf.c is good solution, as userland is not > the only consumer of BPF, think, for example, about ng_bpf. Moreover, > what is the purpose of sampling, after all? BPF was never intended to be > reliable every-packet solution. Certainly other things do use BPF, however in my case I'm not using them, and in the 1 in X solution I have developed so far it can be turned on and off and if it's of huge concern could be put between defines and a kernel config option be required to include it. I'm not looking to transform BPF into a solution to reliably sample every packet, I am looking at attempting to define which packets it discards so that there is an equal chance of sampling something that happens, rather then an unknown/unpredictable chance. I wanted to stop the packet being sent to BPF as high up the kernel chain as possible as to save as much CPU time as possible. There's no point in capturing everything we can and then having the user land program selectively chuck stuff when it could be done before all the various copying/switching/etc. Additionally it would be nice to limit the number of packets that are processed through sampling, running some of our servers at 100% load is not ideal (see point 2 bellow). > If you are monitoring in userland, Snort > of course will not have enough time to process all of your data, so why > not simply put at least two machines in parallel, one for each mirrored > line? 1) This doesn't scale, in the next six to twelve months I'm going to be presented with a 10Gb uplink to our regional network. Now I know I'm going to have issues when that link reaches ~40% capacity anyway, but one thing at a time. 2) We don't have the machine room heat or power capacity spare to run more servers, and there are other projects that require capacity that are in the waiting list way ahead of mine. 3) Because of our constraints we are satisfied with sampled data, we don't need full streams, but we would like controlled sampled data. I'd love to buy a commercial hardware solution, unfortunately my budget is short by about $750k. So here I am with my favourite OS instead. God knows I've benefited from using FreeBSD, as has the institute I work for, at least if I do it properly I can say "guys, it's yours if you want it". So if anyone wouldn't mind having a quick look at my initial email that'd be great. P. -- Peter Wood From owner-freebsd-net@FreeBSD.ORG Mon Jan 7 05:26:01 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B39E116A421 for ; Mon, 7 Jan 2008 05:26:01 +0000 (UTC) (envelope-from Krishnan.Nair@csr.com) Received: from cluster-d.mailcontrol.com (cluster-d.mailcontrol.com [217.69.20.190]) by mx1.freebsd.org (Postfix) with ESMTP id 5081213C447 for ; Mon, 7 Jan 2008 05:26:01 +0000 (UTC) (envelope-from Krishnan.Nair@csr.com) Received: from banasiexb01.ASIA.ROOT.PRI ([202.80.51.116]) by rly02d.srv.mailcontrol.com (MailControl) with ESMTP id m074uwHD020020 for ; Mon, 7 Jan 2008 04:57:00 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 7 Jan 2008 10:26:34 +0530 Message-ID: <610EAA62A0FD314D9761697EEC820CBE59A108@banasiexb01.ASIA.ROOT.PRI> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: User-space PPP source code Thread-Index: AchQ6a1qs9IDLRVpRDaRYo6pyixD9Q== From: "Krishnan Nair" To: X-Scanned-By: MailControl A-08-00-01 (www.mailcontrol.com) on 10.68.0.112 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: User-space PPP source code X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2008 05:26:01 -0000 Hi, =20 I am looking for user-space PPP source code, but couldn't find it. Could you please let me know the path from where I can download it? =20 Thanks and regards Krishnan From owner-freebsd-net@FreeBSD.ORG Mon Jan 7 08:25:08 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 992E416A418 for ; Mon, 7 Jan 2008 08:25:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id 5A4EA13C46E for ; Mon, 7 Jan 2008 08:25:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 1DB5941C734; Mon, 7 Jan 2008 09:25:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id EXGJC8s5s00I; Mon, 7 Jan 2008 09:25:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id C6AF741C730; Mon, 7 Jan 2008 09:25:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 90906444885; Mon, 7 Jan 2008 08:23:07 +0000 (UTC) Date: Mon, 7 Jan 2008 08:23:07 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Krishnan Nair In-Reply-To: <610EAA62A0FD314D9761697EEC820CBE59A108@banasiexb01.ASIA.ROOT.PRI> Message-ID: <20080107082026.J36482@maildrop.int.zabbadoz.net> References: <610EAA62A0FD314D9761697EEC820CBE59A108@banasiexb01.ASIA.ROOT.PRI> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: User-space PPP source code X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2008 08:25:08 -0000 On Mon, 7 Jan 2008, Krishnan Nair wrote: Hi, > I am looking for user-space PPP source code, but couldn't find it. Could > you please let me know the path from where I can download it? it lives in usr.sbin/ppp : http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.sbin/ppp/ How you can get get it is described in this chapter: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/mirrors.html -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT Software is harder than hardware so better get it right the first time. From owner-freebsd-net@FreeBSD.ORG Mon Jan 7 11:07:04 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D053216A543 for ; Mon, 7 Jan 2008 11:07:04 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C105C13C45B for ; Mon, 7 Jan 2008 11:07:04 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m07B74dm061849 for ; Mon, 7 Jan 2008 11:07:04 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m07B741v061845 for freebsd-net@FreeBSD.org; Mon, 7 Jan 2008 11:07:04 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 7 Jan 2008 11:07:04 GMT Message-Id: <200801071107.m07B741v061845@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2008 11:07:04 -0000 Current FreeBSD problem reports Critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- f kern/115360 net [ipv6] IPv6 address and if_bridge don't play well toge 1 problem total. Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- a kern/38554 net changing interface ipaddress doesn't seem to work s kern/39937 net ipstealth issue f kern/62374 net panic: free: multiple frees s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/92552 net A serious bug in most network drivers from 5.X to 6.X s kern/95665 net [if_tun] "ping: sendto: No buffer space available" wit s kern/105943 net Network stack may modify read-only mbuf chain copies o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/108542 net [bce]: Huge network latencies with 6.2-RELEASE / STABL o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112722 net IP v4 udp fragmented packet reject o kern/113457 net [ipv6] deadlock occurs if a tunnel goes down while the o kern/113842 net [ipv6] PF_INET6 proto domain state can't be cleared wi o kern/114714 net [gre][patch] gre(4) is not MPSAFE and does not support o kern/114839 net [fxp] fxp looses ability to speak with traffic o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/116077 net 6.2-STABLE panic during use of multi-cast networking c o kern/116172 net Network / ipv6 recursive mutex panic o kern/116185 net if_iwi driver leads system to reboot o kern/116328 net [bge]: Solid hang with bge interface o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o kern/116837 net ifconfig tunX destroy: panic o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117423 net Duplicate IP on different interfaces o bin/117448 net [carp] 6.2 kernel crash o kern/118880 net [ipv6] IP_RECVDSTADDR & IP_SENDSRCADDR not implemented o kern/119225 net 7.0-RC1 no carrier with Prism 2.5 wifi card 28 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o conf/23063 net [PATCH] for static ARP tables in rc.network s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s kern/60293 net FreeBSD arp poison patch o kern/95267 net packet drops periodically appear f kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/102035 net [plip] plip networking disables parallel port printing o conf/102502 net [patch] ifconfig name does't rename netgraph node in n o conf/107035 net [patch] bridge interface given in rc.conf not taking a o kern/112654 net [pcn] Kernel panic upon if_pcn module load on a Netfin o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o bin/116643 net [patch] fstat(1): add INET/INET6 socket details as in o bin/117339 net [patch] route(8): loading routing management commands o kern/118722 net [tcp] Many old TCP connections in SYN_RCVD state o kern/118727 net [ng] [patch] add new ng_pf module a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o kern/118975 net [bge] [patch] Broadcom 5906 not handled by FreeBSD o bin/118987 net ifconfig -l [address_family] does not work correct on 19 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Jan 7 11:14:38 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 674B916A47C for ; Mon, 7 Jan 2008 11:14:38 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (reverse-25.fdn.fr [80.67.176.25]) by mx1.freebsd.org (Postfix) with ESMTP id 2B5E013C465 for ; Mon, 7 Jan 2008 11:14:38 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: by smtp.zeninc.net (smtpd, from userid 1000) id 313A73F6F; Mon, 7 Jan 2008 11:41:29 +0100 (CET) Date: Mon, 7 Jan 2008 11:41:29 +0100 From: VANHULLEBUS Yvan To: freebsd-net@freebsd.org Message-ID: <20080107104128.GA23718@zen.inc> References: <5a1835cd0801051355tc14f06bja72d8659bd499861@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5a1835cd0801051355tc14f06bja72d8659bd499861@mail.gmail.com> User-Agent: All mail clients suck. This one just sucks less. Subject: Re: ipsec_tools will not compile after IPSEC_NAT_T patch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2008 11:14:38 -0000 On Sat, Jan 05, 2008 at 04:55:21PM -0500, Lyle Scott III wrote: > I applied the IPSEC_NAT_T patch from > http://vanhu.free.fr/FreeBSD/patch-natt-freebsd6-2007-05-31.diff to FreeBSD > 6.2-release-p9 > yesterday to include IPSEC_NAT_T support. > i did a make buildworld buildkernel && make installworld installkernel && > shutdown -r now Hi. To answer your previous mail, you'll need to add IPSEC_NAT_T option to your configuration file, or kernel will be compiled without NAT-T support. > Now when i recompile /usr/ports/security/ipsec-tools it passes the test for > checking if the nat_t patch is installed but the port fails in make. I did > some research and noticed the same function it errors at is in the patch. Do you have the configure's output for this test ? > Did i mess something up or what? I'm not sure where to go from here. > Should i just delete /usr/src/* and extract a new src and start over? > > cc -DHAVE_CONFIG_H -I. -I../.. -I./../libipsec > -I./../../src/racoon/missing -D_GNU_SOURCE > -DSYSCONFDIR=\"/usr/local/etc/racoon\" -DADMINPORTDIR=\"/var/db/racoon\" > -pipe -g -Wall -Werror -Wno-unused -MT isakmp.o -MD -MP -MF > .deps/isakmp.Tpo -c -o isakmp.o isakmp.c > isakmp.c: In function `isakmp_open': > isakmp.c:1750: error: `UDP_ENCAP_ESPINUDP' undeclared (first use in this > function) > isakmp.c:1750: error: (Each undeclared identifier is reported only once > isakmp.c:1750: error: for each function it appears in.) > isakmp.c:1753: error: `UDP_ENCAP_ESPINUDP_NON_IKE' undeclared (first use in > this function) > isakmp.c:1757: error: `UDP_ENCAP' undeclared (first use in this function) > *** Error code 1 Those defines are in netinet/udp.h Please check if they are in your /usr/include/netinet/udp.h If you find them there, that means your problem comes from your shell's environment (check SYSDIR, etc...). If you don't find those defines in /usr/include/netinet/udp.h, check in /usr/src/sys/netinet/udp.h If you find them, that means you had a problem while installing world, if you didn't find them, that means you had a problem while applying the patch. Yvan. -- NETASQ http://www.netasq.com From owner-freebsd-net@FreeBSD.ORG Mon Jan 7 14:53:37 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7684116A469 for ; Mon, 7 Jan 2008 14:53:37 +0000 (UTC) (envelope-from vadim_nuclight@mail.ru) Received: from mx40.mail.ru (mx40.mail.ru [194.67.23.36]) by mx1.freebsd.org (Postfix) with ESMTP id F1AD813C468 for ; Mon, 7 Jan 2008 14:53:36 +0000 (UTC) (envelope-from vadim_nuclight@mail.ru) Received: from [78.140.2.250] (port=21741 helo=nuclight.avtf.net) by mx40.mail.ru with esmtp id 1JBtM7-000CrV-00; Mon, 07 Jan 2008 17:53:35 +0300 Date: Mon, 07 Jan 2008 20:53:31 +0600 To: "Peter Wood" , freebsd-net@freebsd.org References: <4781337B.40104@alastria.net> <47814FC7.6080106@alastria.net> From: "Vadim Goncharov" Organization: AVTF TPU Hostel Content-Type: text/plain; format=flowed; delsp=yes; charset=koi8-r MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <47814FC7.6080106@alastria.net> User-Agent: Opera M2/7.54 (Win32, build 3865) Cc: Subject: Re: Implementation of Sampling for BPF X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2008 14:53:37 -0000 07.01.08 @ 04:01 Peter Wood wrote: >> I don't think that modifying bpf.c is good solution, as userland is not >> the only consumer of BPF, think, for example, about ng_bpf. Moreover, >> what is the purpose of sampling, after all? BPF was never intended to >> be reliable every-packet solution. > > Certainly other things do use BPF, however in my case I'm not using > them, and in the 1 in X solution I have developed so far it can be > turned on and off and if it's of huge concern could be put between > defines and a kernel config option be required to include it. It's the question of doing things correctly(tm) so they are appropriate for inclusion into the main src tree of the FreeBSD Project - this must be universal enough to meet other people needs and to be supported. You of course are free to do any patches at your locals site for your individual needs - many people do that customization on their own. > I'm not looking to transform BPF into a solution to reliably sample > every packet, I am looking at attempting to define which packets it > discards so that there is an equal chance of sampling something that > happens, rather then an unknown/unpredictable chance. So what if a malicious packet will be skipped due sampling, packet which is by other means undistinguishable from others before detailed analysis? > I wanted to stop the packet being sent to BPF as high up the kernel > chain as possible as to save as much CPU time as possible. There's no > point in capturing everything we can and then having the user land > program selectively chuck stuff when it could be done before all the > various copying/switching/etc. Low in chain instead of high, you mean? That's of course no point to sort out things in userland, but that's properties of given BPF program to filter - how much the userland program wants to receive before detailed analysis. >> If you are monitoring in userland, Snort of course will not have enough >> time to process all of your data, so why not simply put at least two >> machines in parallel, one for each mirrored line? > > 1) This doesn't scale, in the next six to twelve months I'm going to be > presented with a 10Gb uplink to our regional network. Now I know I'm > going to have issues when that link reaches ~40% capacity anyway, but > one thing at a time. > > 2) We don't have the machine room heat or power capacity spare to run > more servers, and there are other projects that require capacity that > are in the waiting list way ahead of mine. > I'd love to buy a commercial hardware solution, unfortunately my budget > is short by about $750k. So here I am with my favourite OS instead. God > knows I've benefited from using FreeBSD, as has the institute I work > for, at least if I do it properly I can say "guys, it's yours if you > want it". Putting as many servers as needed does scale well if you need only sampled data - just put an appropriate sampler/load balancer before them. And using FreeBSD on that servers will be cheaper than commercial hardware solution, too. > 3) Because of our constraints we are satisfied with sampled data, we > don't need full streams, but we would like controlled sampled data. Why sample is enough to you? What exactly do you need? May be you'd rather write some simpler expressions for in-kernel filtering instead of heavy-weighted Snort? -- WBR, Vadim Goncharov From owner-freebsd-net@FreeBSD.ORG Mon Jan 7 16:31:27 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D0A916A476 for ; Mon, 7 Jan 2008 16:31:27 +0000 (UTC) (envelope-from peter@alastria.net) Received: from nebula.thdo.uk.alastria.net (unknown [IPv6:2001:ba8:0:1f0::5]) by mx1.freebsd.org (Postfix) with ESMTP id B6CBF13C455 for ; Mon, 7 Jan 2008 16:31:26 +0000 (UTC) (envelope-from peter@alastria.net) Received: from [10.10.4.10] (dragon.lancs.uk.alastria.net [88.96.139.34]) (authenticated bits=0) by nebula.thdo.uk.alastria.net (8.13.3/8.13.3) with ESMTP id m07GVc73092048 for ; Mon, 7 Jan 2008 16:31:38 GMT (envelope-from peter@alastria.net) Message-ID: <478253D5.4010900@alastria.net> Date: Mon, 07 Jan 2008 16:31:17 +0000 From: Peter Wood Organization: Alastria Networks Limited User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <4781337B.40104@alastria.net> <47814FC7.6080106@alastria.net> In-Reply-To: Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Flag: NO X-Virus-Status: No X-Spam-Score: 0.137 () RCVD_IN_SORBS_DUL X-Spam-Ultra-Flag: NO X-Spam-Low-Flag: NO X-Spam-Flag: NO X-Spam-High-Flag: NO X-Scanned-By: MIMEDefang 2.51 on 212.13.198.8 Subject: Re: Implementation of Sampling for BPF X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2008 16:31:27 -0000 Good Afternoon, > It's the question of doing things correctly(tm) so they are appropriate > for inclusion into the main src tree of the FreeBSD Project - this must > be universal enough to meet other people needs and to be supported. You > of course are free to do any patches at your locals site for your > individual needs - many people do that customization on their own. Indeed, and the later part of your statement is what my primary goal is, however I'm unfamiliar with this part of the kernel and could do with a few pointers about what the correct way would be from a programmatic point of view. > So what if a malicious packet will be skipped due sampling, packet which > is by other means undistinguishable from others before detailed analysis? If this case happens it is unfortunate and it slips through the net, however malicious problems that I look for are more often flows rather then individual packets. We drop most protocols at the border that would give us an issue with one packet. There is a greater chance of managing to sample at least one packet of a malicious flow. > Low in chain instead of high, you mean? That's of course no point to > sort out things in userland, but that's properties of given BPF program > to filter - how much the userland program wants to receive before > detailed analysis. Please forgive my use of low and high, it seems to depend on which end of the stack you're looking from :). I meant as close to it coming into the kernel as possible, yes. > Putting as many servers as needed does scale well if you need only > sampled data - just put an appropriate sampler/load balancer before > them. And using FreeBSD on that servers will be cheaper than commercial > hardware solution, too. Again, no ability to buy a sampler/load balancer, nor any space/heat/power to run one in. My available equipment consists of two core networking devices, some fibre, two Intel gig optical cards and one powerful(ish) Dell server currently running FreeBSD 6.X, which needs bumping to 7.0 when it's released. The kit at the other end of these optical links is either busy or incapable of sampling. > Why sample is enough to you? What exactly do you need? May be you'd > rather write some simpler expressions for in-kernel filtering instead of > heavy-weighted Snort? I'm afraid I will not discuss our exact requirements in an open forum, this seems unwise from a security point of view. I would be happy to implement this as a BPF filter, but I'm unaware of how sample in the filter language and count with variables, rather then look at fields in a packet. More additional uses I could possibly foresee: * NetFlow Generation - For which sampling is perfectly acceptable, although we currently do this in hardware. * Statistics Generation - What are our users using our network for, etc. Now of course a lot of this data can be obtained from NetFlow (as we do at current) but there are aspects that can't, like average packet sizes per protocol, etc, things like that. * Research - I'm regularly asked for sampled data from our network from researchers (which currently I turn down) but I'm assuming that they think sampled data is quite suitable. I can understand your hesitation about including something like this in the project as a whole, but as I've said this is primarily for our purposes. If others would find it useful that's great and I'll maintain a patch on a webserver, if the project as a whole would find it useful that's great too. It would be nice at least from a academic point of view for FreeBSD to support other research too, for example the work being done to separate the congestion control to permit easier testing of different methods. P. -- Peter Wood From owner-freebsd-net@FreeBSD.ORG Mon Jan 7 17:28:54 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6ADFB16A46E; Mon, 7 Jan 2008 17:28:54 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 3B83A13C457; Mon, 7 Jan 2008 17:28:54 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (remko@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m07HSscY030970; Mon, 7 Jan 2008 17:28:54 GMT (envelope-from remko@freefall.freebsd.org) Received: (from remko@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m07HSsFl030966; Mon, 7 Jan 2008 17:28:54 GMT (envelope-from remko) Date: Mon, 7 Jan 2008 17:28:54 GMT Message-Id: <200801071728.m07HSsFl030966@freefall.freebsd.org> To: remko@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: remko@FreeBSD.org Cc: Subject: Re: kern/119361: [bge] bge(4) transmit performance problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2008 17:28:54 -0000 Synopsis: [bge] bge(4) transmit performance problem Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Mon Jan 7 17:28:37 UTC 2008 Responsible-Changed-Why: reassign to -net team http://www.freebsd.org/cgi/query-pr.cgi?pr=119361 From owner-freebsd-net@FreeBSD.ORG Mon Jan 7 17:29:15 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BEF6D16A41A; Mon, 7 Jan 2008 17:29:15 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8F4BF13C44B; Mon, 7 Jan 2008 17:29:15 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (remko@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m07HTFt2031075; Mon, 7 Jan 2008 17:29:15 GMT (envelope-from remko@freefall.freebsd.org) Received: (from remko@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m07HTFi1031071; Mon, 7 Jan 2008 17:29:15 GMT (envelope-from remko) Date: Mon, 7 Jan 2008 17:29:15 GMT Message-Id: <200801071729.m07HTFi1031071@freefall.freebsd.org> To: remko@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: remko@FreeBSD.org Cc: Subject: Re: kern/109470: [wi] Orinoco Classic Gold PC Card Can't Channel Hop X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2008 17:29:15 -0000 Synopsis: [wi] Orinoco Classic Gold PC Card Can't Channel Hop Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Mon Jan 7 17:29:15 UTC 2008 Responsible-Changed-Why: Over to maintainer. http://www.freebsd.org/cgi/query-pr.cgi?pr=109470 From owner-freebsd-net@FreeBSD.ORG Mon Jan 7 17:29:23 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B82ED16A417; Mon, 7 Jan 2008 17:29:23 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 877CF13C469; Mon, 7 Jan 2008 17:29:23 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (remko@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m07HTNMv031163; Mon, 7 Jan 2008 17:29:23 GMT (envelope-from remko@freefall.freebsd.org) Received: (from remko@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m07HTNen031159; Mon, 7 Jan 2008 17:29:23 GMT (envelope-from remko) Date: Mon, 7 Jan 2008 17:29:23 GMT Message-Id: <200801071729.m07HTNen031159@freefall.freebsd.org> To: remko@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: remko@FreeBSD.org Cc: Subject: Re: kern/117043: [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM Checksum is Not Valid X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2008 17:29:23 -0000 Synopsis: [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM Checksum is Not Valid Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Mon Jan 7 17:29:23 UTC 2008 Responsible-Changed-Why: Over to maintainer. http://www.freebsd.org/cgi/query-pr.cgi?pr=117043 From owner-freebsd-net@FreeBSD.ORG Mon Jan 7 17:33:19 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 372AB16A41A; Mon, 7 Jan 2008 17:33:19 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 0713913C455; Mon, 7 Jan 2008 17:33:19 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (remko@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m07HXIps038775; Mon, 7 Jan 2008 17:33:18 GMT (envelope-from remko@freefall.freebsd.org) Received: (from remko@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m07HXIDJ038771; Mon, 7 Jan 2008 17:33:18 GMT (envelope-from remko) Date: Mon, 7 Jan 2008 17:33:18 GMT Message-Id: <200801071733.m07HXIDJ038771@freefall.freebsd.org> To: remko@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: remko@FreeBSD.org Cc: Subject: Re: kern/119345: [ath] Unsuported Atheros 5424/2424 and CPU speedstep not recognized X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2008 17:33:19 -0000 Synopsis: [ath] Unsuported Atheros 5424/2424 and CPU speedstep not recognized Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Mon Jan 7 17:33:18 UTC 2008 Responsible-Changed-Why: For the if_ath part move over to -net http://www.freebsd.org/cgi/query-pr.cgi?pr=119345 From owner-freebsd-net@FreeBSD.ORG Mon Jan 7 19:20:14 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7BCE116A421 for ; Mon, 7 Jan 2008 19:20:14 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.188]) by mx1.freebsd.org (Postfix) with ESMTP id 0382913C465 for ; Mon, 7 Jan 2008 19:20:13 +0000 (UTC) (envelope-from max@love2party.net) Received: from amd64.laiers.local (dslb-088-067-233-103.pools.arcor-ip.net [88.67.233.103]) by mrelayeu.kundenserver.de (node=mrelayeu8) with ESMTP (Nemesis) id 0ML31I-1JBxW81Nbd-0002uN; Mon, 07 Jan 2008 20:20:12 +0100 From: Max Laier Organization: FreeBSD To: freebsd-net@freebsd.org Date: Mon, 7 Jan 2008 20:20:04 +0100 User-Agent: KMail/1.9.7 X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<%}*_BD U_or=\mOZf764&nYj=JYbR1PW0ud>|!~, , CPC.1-D$FG@0h3#'5"k{V]a~. X-Provags-ID: V01U2FsdGVkX1/XjI1GIpu5FyKVU5iKHDZssJTkvboL81J4+K/ ccxsCHIcx/01s2O5U4a32nxooqvmKZOs4tGpxRdJjUp4fJioNR MX32023xwWvkHLAT8GvhMOA5YYNTFmf5zSIoxWhs3s= Subject: OT: ifconfig bridge0 span foo0 (under linux) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2008 19:20:14 -0000 --nextPart1521769.qm18ihCrLa Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, real quick OT question: I have to move a setup to Linux :-\ and can't=20 figure out how to do span ports with linux' brctl (or otherwise). If any=20 of you happen to know, please let me know. This experiment made me - once again - appreciate the central=20 documentation of FreeBSD. With Linux I just don't know where to look :-\ Thanks and sorry for the noise, but I'm desperate by now. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart1521769.qm18ihCrLa Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBHgntqXyyEoT62BG0RAmcJAJwMEA8yWfnGz9grht7N1Va07QVRzQCfUQi2 LOTbdzowmb4mbYw6/VT/zf4= =v8Yj -----END PGP SIGNATURE----- --nextPart1521769.qm18ihCrLa-- From owner-freebsd-net@FreeBSD.ORG Mon Jan 7 20:13:23 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D70116A417; Mon, 7 Jan 2008 20:13:23 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 680E213C43E; Mon, 7 Jan 2008 20:13:23 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m07KDNLR048112; Mon, 7 Jan 2008 20:13:23 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m07KDN2O048108; Mon, 7 Jan 2008 20:13:23 GMT (envelope-from linimon) Date: Mon, 7 Jan 2008 20:13:23 GMT Message-Id: <200801072013.m07KDN2O048108@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/119432: route add -host -iface causes arp entry with nic's arp address (regression) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2008 20:13:23 -0000 Synopsis: route add -host -iface causes arp entry with nic's arp address (regression) Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Jan 7 20:13:12 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=119432 From owner-freebsd-net@FreeBSD.ORG Tue Jan 8 18:29:45 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7461A16A419; Tue, 8 Jan 2008 18:29:45 +0000 (UTC) (envelope-from vadimnuclight@tpu.ru) Received: from relay1.tpu.ru (relay1.tpu.ru [213.183.112.102]) by mx1.freebsd.org (Postfix) with ESMTP id A5D5513C455; Tue, 8 Jan 2008 18:29:44 +0000 (UTC) (envelope-from vadimnuclight@tpu.ru) Received: from localhost (localhost.localdomain [127.0.0.1]) by relay1.tpu.ru (Postfix) with ESMTP id 1C8181048BF; Wed, 9 Jan 2008 00:29:42 +0600 (NOVT) X-Virus-Scanned: amavisd-new at tpu.ru Received: from relay1.tpu.ru ([127.0.0.1]) by localhost (relay1.tpu.ru [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f3E19LpcdGLu; Wed, 9 Jan 2008 00:29:39 +0600 (NOVT) Received: from mail.main.tpu.ru (mail.main.tpu.ru [10.0.0.3]) by relay1.tpu.ru (Postfix) with ESMTP id 486D0104888; Wed, 9 Jan 2008 00:29:39 +0600 (NOVT) Received: from mail.tpu.ru ([213.183.112.105]) by mail.main.tpu.ru with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Jan 2008 00:29:38 +0600 Received: from nuclight.avtf.net ([82.117.64.107]) by mail.tpu.ru over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Jan 2008 00:29:33 +0600 Date: Wed, 09 Jan 2008 00:29:28 +0600 To: "Andre Oppermann" References: <4772F123.5030303@elischer.org> <477416CC.4090906@elischer.org> <477D2EF3.2060909@elischer.org> <4780E5E7.2070202@FreeBSD.org> <4781197F.1000105@elischer.org> <47814AF0.9070509@freebsd.org> From: "Vadim Goncharov" Organization: AVTF TPU Hostel Content-Type: text/plain; format=flowed; delsp=yes; charset=koi8-r MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <47814AF0.9070509@freebsd.org> User-Agent: Opera M2/7.54 (Win32, build 3865) X-OriginalArrivalTime: 08 Jan 2008 18:29:33.0482 (UTC) FILETIME=[6A3E30A0:01C85224] Cc: Qing Li , FreeBSD Net , arch@freebsd.org, Ivo Vachkov , Robert Watson , Julian Elischer , "Bruce M. Simpson" Subject: Re: resend: multiple routing table roadmap (format fix) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2008 18:29:45 -0000 07.01.08 @ 03:41 Andre Oppermann wrote: > Vadim Goncharov wrote: >> 07.01.08 @ 00:10 Julian Elischer wrote: >> >>>>> Is multicast and multipath routing the same? >>>> No. They are currently orthogonal. >>>> However it makes sense to merge the multicast and unicast forwarding >>>> code as currently MROUTING is limited to a fan-out of 32 next-hops >>>> only. In multicast, next-hops are normally just interfaces. >>>> Also the IETF MANET ad-hoc IP is going to need hooks there; >>>> multicast in MANET needs to address its next-hops by their unicast >>>> address, and encapsulate the traffic with a header. This is not true >>>> link layer multicast -- although it might use link layer multicast to >>>> leverage the hash filters in 802.11 MACs. >>>> As regards getting ARP out of forwarding tables, this should have >>>> happened a long time ago... >>> >>> I'm not 100 % convinced of this... >>> I was, but I think there may still be a place for a cached arp pointer >>> in hte next hop route to the arp entry for that next hop. >>> I DO however thing that the arp stuff should nto be accessing its >>> data via the routing table. >> Surely, routing table should contain a cached pointer to an entry in >> L2 table (ARP in case of Ethernet), to not do double lookups. But still >> separate those tables... > > Locking hell over again. How do you remove an ARP entry without doing > a full walk over the entire routing table (some 250K entries for the > DFZ)? Make it rmlocks and be done with it. Why a full walk, why such a dumb way? To remove an ARP entry for host A.B.C.D in L2 table of form (A.B.C.D -> 00:01:02:03:04:05), it is enough to do a (usual speed) routing lookup for host A.B.C.D and modify a one pointer in it's rtentry to NULL or remove rtentry (if it's selected to be implemented as cloned). Thus, when on regular forwarding (table read) a routing lookup is done, we already have a FAST access - one pointer dereference - for it's L2 table entry, be it ARP or any other L2 type (which support becoming easily with separation of L2 and L3). And on every modification of L2 table - which is RARE - do lookup with usual speed to modify cached pointer. Compare it with a scheme where for EVERY forwarded packet, there is a need for DOUBLE lookup - after a routing one, do another in L2 table. Current routing table implementation, with all disadvantages of combining L2 and L3, have from the same combinig a one HUGE benefit - performance. And never, ever, ever, ever even try to split L2 from L3 with losing that performance - then it should be still never split, despite all disadvantages, and you'll become an enemy of many, many users. Especially while caching allows to do things reasonably fast. -- WBR, Vadim Goncharov From owner-freebsd-net@FreeBSD.ORG Tue Jan 8 18:46:50 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B9B716A417 for ; Tue, 8 Jan 2008 18:46:50 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id 526B913C457 for ; Tue, 8 Jan 2008 18:46:50 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from bcs-mail2.internal.cacheflow.com (bcs-mail2.internal.cacheflow.com [10.2.2.59]) by whisker.bluecoat.com (8.13.8/8.13.8) with ESMTP id m08IkkkN029628; Tue, 8 Jan 2008 10:46:47 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 8 Jan 2008 10:46:42 -0800 Message-ID: <305C539CA2F86249BF51CDCE8996AFF4096E123E@bcs-mail2.internal.cacheflow.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: resend: multiple routing table roadmap (format fix) Thread-Index: AchQp56/Ql+VUKdpSjGv0EsTFz+khQBfunIg References: <4772F123.5030303@elischer.org> <477416CC.4090906@elischer.org> <477D2EF3.2060909@elischer.org><4780E5E7.2070202@FreeBSD.org> <4781197F.1000105@elischer.org> From: "Li, Qing" To: "Vadim Goncharov" , "Julian Elischer" , "Bruce M. Simpson" Cc: arch@freebsd.org, Ivo Vachkov , Robert Watson , FreeBSD Net , Qing Li Subject: RE: resend: multiple routing table roadmap (format fix) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2008 18:46:50 -0000 >=20 > Surely, routing table should contain a cached pointer to an=20 > entry in L2 table (ARP in case of Ethernet), to not do double=20 > lookups. But still separate those tables... >=20 The routing table contains only the interface route, from this interface route the L2 table is accessed for on net hosts. So it's a one-to-many relationship. How do you propose the L2 entry caching be done ? -- Qing From owner-freebsd-net@FreeBSD.ORG Tue Jan 8 19:03:58 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB29116A419; Tue, 8 Jan 2008 19:03:58 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id 337DB13C448; Tue, 8 Jan 2008 19:03:57 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from bcs-mail2.internal.cacheflow.com (bcs-mail2.internal.cacheflow.com [10.2.2.59]) by whisker.bluecoat.com (8.13.8/8.13.8) with ESMTP id m08J3rpv001532; Tue, 8 Jan 2008 11:03:53 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 8 Jan 2008 11:03:47 -0800 Message-ID: <305C539CA2F86249BF51CDCE8996AFF4096E12A7@bcs-mail2.internal.cacheflow.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: resend: multiple routing table roadmap (format fix) Thread-Index: AchSJHwwqXVcLPAaSm26guZBFGjinAAAsGMg References: <4772F123.5030303@elischer.org> <477416CC.4090906@elischer.org> <477D2EF3.2060909@elischer.org> <4780E5E7.2070202@FreeBSD.org><4781197F.1000105@elischer.org> <47814AF0.9070509@freebsd.org> From: "Li, Qing" To: "Vadim Goncharov" , "Andre Oppermann" Cc: Qing Li , FreeBSD Net , arch@freebsd.org, Ivo Vachkov , Robert Watson , Julian Elischer , "Bruce M. Simpson" Subject: RE: resend: multiple routing table roadmap (format fix) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2008 19:03:58 -0000 >=20 > Why a full walk, why such a dumb way?=20 > Correct, we don't do a full walk.=20 > > To remove an ARP entry for host A.B.C.D in L2 table of form=20 > (A.B.C.D -> 00:01:02:03:04:05), it is enough to do a (usual speed)=20 > routing lookup for host A.B.C.D and modify a one pointer in=20 > it's rtentry to NULL or remove rtentry (if it's selected to=20 > be implemented as cloned). Thus, when on regular forwarding=20 > (table read) a routing lookup is done, we already have a FAST=20 > access - one pointer dereference - for it's L2 table entry,=20 > be it ARP or any other L2 type (which support becoming easily=20 > with separation of L2 and L3). And on every modification of=20 > L2 table - which is RARE - do lookup with usual speed to=20 > modify cached pointer. Compare it with a scheme where for=20 > EVERY forwarded packet, there is a need for DOUBLE lookup -=20 > after a routing one, do another in L2 table. >=20 Is it really a double lookup though ? =20 With the current routing table that contains the ARP entries, a search has to proceed pass the interface route further down=20 the routing tree, and the depth depends on the number of ARP=20 entries in the table. With L2/L3 seperation, the routing search stops at the interface route, and further search for the exact entry continues in a separate L2 table. From a high level it does seem there could be performance issues such as cache invalidation problem, however, I cannot quantify at this point what that degration translates into,=20 and what impact it has on the overall scheme of things. I am not sure if anyone can quantify such performance question at this point. > > Current routing table implementation, with all disadvantages=20 > of combining > L2 and L3, have from the same combinig a one HUGE benefit -=20 > performance. =20 > And never, ever, ever, ever even try to split L2 from L3 with=20 > losing that performance - then it should be still never=20 > split, despite all disadvantages, and you'll become an enemy=20 > of many, many users. Especially while caching allows to do=20 > things reasonably fast. >=20 No disagreement here. -- Qing From owner-freebsd-net@FreeBSD.ORG Tue Jan 8 19:59:58 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9695916A41B for ; Tue, 8 Jan 2008 19:59:58 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 5FC3413C4EE for ; Tue, 8 Jan 2008 19:59:58 +0000 (UTC) (envelope-from sam@errno.com) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id m08Jxsc6080601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Jan 2008 11:59:56 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <4783D63A.7060502@errno.com> Date: Tue, 08 Jan 2008 11:59:54 -0800 From: Sam Leffler User-Agent: Thunderbird 2.0.0.9 (X11/20071125) MIME-Version: 1.0 To: Randy Bush References: <18299.42791.826406.76763@roam.psg.com> <18302.50925.780884.908062@roam.psg.com> In-Reply-To: <18302.50925.780884.908062@roam.psg.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC--Metrics: ebb.errno.com; whitelist Cc: FreeBSD Net Subject: Re: ath0 Ierrs X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2008 19:59:58 -0000 Randy Bush wrote: > just for giggles i un-hacked the mtus and ran for an hour with no > one using the wireless > > soek0.psg.com:/root# netstat -i > Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll > vr0 1500 00:00:24:c8:b3:28 19022 0 16015 0 0 > vr1 1500 00:00:24:c8:b3:29 0 0 51 0 0 > vr2 1500 00:00:24:c8:b3:2a 20 0 66 0 0 > vr3 1500 00:00:24:c8:b3:2b 15710 0 32628 0 0 > ath0 1500 00:0b:6b:83:59:25 0 737819 185 0 0 > lo0 16384 40 0 40 0 0 > lo0 16384 fe80:6::1 fe80:6::1 0 - 0 - - > lo0 16384 localhost ::1 0 - 0 - - > lo0 16384 your-net localhost 42 - 42 - - > bridg 1500 d6:3e:c6:9c:31:a7 15732 0 18559 0 0 > bridg 1500 192.168.0.0 soek0 143 - 382 - - > tun0 1454 18938 0 15926 0 0 > tun0 1454 210.138.216.5 50.216.138.210.bn 1293 - 765 - - > > note the 737819 Ierrs with zero actually packets on the wire. > > how do i debug? > > this is a metrix CM9 miniPCI () in > a soekris 5501 running very -current. > > ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) > ath0: mem 0xa0010000-0xa001ffff irq 15 at device 17.0 on pci0 > ath0: [ITHREAD] > ath0: using obsoleted if_watchdog interface > ath0: Ethernet address: 00:0b:6b:83:59:25 > ath0: mac 5.9 phy 4.3 radio 3.6 > > how do i debug? > athstats From owner-freebsd-net@FreeBSD.ORG Tue Jan 8 22:01:19 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6B2416A417 for ; Tue, 8 Jan 2008 22:01:19 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.186]) by mx1.freebsd.org (Postfix) with ESMTP id 5F48E13C45B for ; Tue, 8 Jan 2008 22:01:19 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: by fk-out-0910.google.com with SMTP id b27so12354676fka.11 for ; Tue, 08 Jan 2008 14:01:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:message-id:from:to:cc:subject:in-reply-to:references:user-agent:mime-version:content-type:sender; bh=SHNsX/Gt/HAPKEDoNtQnE8wd64Z8Ia5IM4yl8Kc2pAE=; b=uhxPHeuFKfzeAEFZl9/zTIna1I4Lbd9rQdU1Aif58uPRvy04lt9yK6CFi5NmvMnb8rsNxpyIWqC/LDHNgy1J1zfKx4o8LRkRKm1Pg8D0zrXyZeXKwDkZpN9CYwRHOzPmfMXq50JIgttTAu/P+UHSD8CP4EoAPrc+6OUClQtCZdI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:message-id:from:to:cc:subject:in-reply-to:references:user-agent:mime-version:content-type:sender; b=k/xTJOM7jq4EeGR+UUTxi8RrQLdvf5G+6xbwrrf/d4Ug4bzf9qif4p07pDKbviSwY6ZTBe95C5RsBafChdLzGjIOfoAeJQ8giCjSYMvMXCa/nMK7U+ASlthhBx8Lh6c6ve594Eoje+SdnlFRg0tI3RM8iyGC4JZ/zAOTYXONzCc= Received: by 10.78.149.15 with SMTP id w15mr25416117hud.72.1199827948448; Tue, 08 Jan 2008 13:32:28 -0800 (PST) Received: from epsilon.local.gmail.com ( [78.130.68.105]) by mx.google.com with ESMTPS id 35sm909922nfu.12.2008.01.08.13.32.20 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 08 Jan 2008 13:32:27 -0800 (PST) Date: Tue, 08 Jan 2008 21:31:59 +0000 Message-ID: <864pdongvk.wl%rpaulo@fnop.net> From: Rui Paulo To: "Bruce M. Simpson" In-Reply-To: <477F674F.7020706@FreeBSD.org> References: <20080104215626.GA88922@goku.pumpky.net> <477F674F.7020706@FreeBSD.org> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: Rui Paulo Cc: "Crist J. Clark" , net@freebsd.org Subject: Re: Text for IPv6 Scope X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2008 22:01:19 -0000 At Sat, 05 Jan 2008 11:17:35 +0000, Bruce M. Simpson wrote: > > Crist J. Clark wrote: > > Anyone up for adding text to the scopeid field in the ifconfig(8) > > output for IPv6 addresses? Other OSes do. To avoid too much > > disruption to the current format, the text is appended after the > > currently printed hexadecimal field. > > > > Example: > > > > fxp0: flags=8843 mtu 1500 > > options=8 > > inet6 fe80::290:27ff:fe13:2540%fxp0 prefixlen 64 scopeid 0x5(site-local) > > > > While we're at it, update the in6.h file to include all scopes > > in RFC4291. > > > > Look OK? Anyone up for applying these? > > > > This kind of output might be cooler? > > fxp0: flags=8843 mtu 1500 > options=8 > inet6 fe80::290:27ff:fe13:2540%fxp0 prefixlen 64 scope site > > > just my 2c > BMS Yes, I would want something like this too, we don't really need the numbers. Regards. -- Rui Paulo From owner-freebsd-net@FreeBSD.ORG Tue Jan 8 22:05:10 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F392916A46B for ; Tue, 8 Jan 2008 22:05:09 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 664A713C447 for ; Tue, 8 Jan 2008 22:05:09 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 75516 invoked from network); 8 Jan 2008 21:29:18 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 8 Jan 2008 21:29:18 -0000 Message-ID: <4783F398.801@freebsd.org> Date: Tue, 08 Jan 2008 23:05:12 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: "Li, Qing" References: <4772F123.5030303@elischer.org> <477416CC.4090906@elischer.org> <477D2EF3.2060909@elischer.org> <4780E5E7.2070202@FreeBSD.org><4781197F.1000105@elischer.org> <47814AF0.9070509@freebsd.org> <305C539CA2F86249BF51CDCE8996AFF4096E12A7@bcs-mail2.internal.cacheflow.com> In-Reply-To: <305C539CA2F86249BF51CDCE8996AFF4096E12A7@bcs-mail2.internal.cacheflow.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Qing Li , FreeBSD Net , arch@freebsd.org, Ivo Vachkov , Robert Watson , Vadim Goncharov , "Bruce M. Simpson" , Julian Elischer Subject: Re: resend: multiple routing table roadmap (format fix) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2008 22:05:10 -0000 Li, Qing wrote: >> To remove an ARP entry for host A.B.C.D in L2 table of form >> (A.B.C.D -> 00:01:02:03:04:05), it is enough to do a (usual speed) >> routing lookup for host A.B.C.D and modify a one pointer in >> it's rtentry to NULL or remove rtentry (if it's selected to >> be implemented as cloned). Thus, when on regular forwarding >> (table read) a routing lookup is done, we already have a FAST >> access - one pointer dereference - for it's L2 table entry, >> be it ARP or any other L2 type (which support becoming easily >> with separation of L2 and L3). And on every modification of >> L2 table - which is RARE - do lookup with usual speed to >> modify cached pointer. Compare it with a scheme where for >> EVERY forwarded packet, there is a need for DOUBLE lookup - >> after a routing one, do another in L2 table. >> > > Is it really a double lookup though ? > > With the current routing table that contains the ARP entries, > a search has to proceed pass the interface route further down > the routing tree, and the depth depends on the number of ARP > entries in the table. > > With L2/L3 seperation, the routing search stops at the interface > route, and further search for the exact entry continues > in a separate L2 table. > > From a high level it does seem there could be performance > issues such as cache invalidation problem, however, I cannot > quantify at this point what that degration translates into, > and what impact it has on the overall scheme of things. > I am not sure if anyone can quantify such performance question > at this point. No. We have to profile the new implementation together with the appropriate locking changes. >> Current routing table implementation, with all disadvantages >> of combining >> L2 and L3, have from the same combinig a one HUGE benefit - >> performance. >> And never, ever, ever, ever even try to split L2 from L3 with >> losing that performance - then it should be still never >> split, despite all disadvantages, and you'll become an enemy >> of many, many users. Especially while caching allows to do >> things reasonably fast. >> > > No disagreement here. We have to consider two aspects here: 1. the locking changes (for example switching to rmlocks which are way less expensive than even normal rmlocks or mutexes) *may* compensate for the additional table lookup. 2. architectual benefits from a clear and strict layering that help us to easily maintain and develop the code in the future *provided* the performance impact is only very small. Having a clean architecture is well worth maybe one to three percent performance in the mid and long term IMHO. People with the ultimate need for speed have to maintain their own trees anyway (Bluecoat, Juniper, Sandvine, Isilon,...) and can afford to cut some more corners anyway. If one is tuning a machine for a very particular purpose one can tightly glue layers together without having to take care of general purpose principles of a generic operating system as the stock FreeBSD is. I'm all for squeezing out the last bit of performance in stock FreeBSD, however not at the expense of a clean system architecture. Almost all attempts to cut those corners have bitten us badly after only a few number of moons when underlying hardware realities change (see P-IV Netburst assumptions vs. current Core2/AMD64 reality; nobody really cares about Netburst and its horrible locking overhead anymore). -- Andre From owner-freebsd-net@FreeBSD.ORG Tue Jan 8 22:38:30 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7CFEE16A46B for ; Tue, 8 Jan 2008 22:38:30 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id 4F58913C4D1 for ; Tue, 8 Jan 2008 22:38:30 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 6F86141C75C for ; Tue, 8 Jan 2008 23:20:08 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id Jn9m44bMait9 for ; Tue, 8 Jan 2008 23:20:08 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 1B58B41C75B; Tue, 8 Jan 2008 23:20:08 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 3E83D444885 for ; Tue, 8 Jan 2008 22:18:10 +0000 (UTC) Date: Tue, 8 Jan 2008 22:18:10 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: net@freebsd.org In-Reply-To: <864pdongvk.wl%rpaulo@fnop.net> Message-ID: <20080108220558.L36482@maildrop.int.zabbadoz.net> References: <20080104215626.GA88922@goku.pumpky.net> <477F674F.7020706@FreeBSD.org> <864pdongvk.wl%rpaulo@fnop.net> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: Re: Text for IPv6 Scope X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2008 22:38:30 -0000 On Tue, 8 Jan 2008, Rui Paulo wrote: > At Sat, 05 Jan 2008 11:17:35 +0000, > Bruce M. Simpson wrote: >> >> Crist J. Clark wrote: >>> Anyone up for adding text to the scopeid field in the ifconfig(8) >>> output for IPv6 addresses? Other OSes do. To avoid too much >>> disruption to the current format, the text is appended after the >>> currently printed hexadecimal field. >>> >>> Example: >>> >>> fxp0: flags=8843 mtu 1500 >>> options=8 >>> inet6 fe80::290:27ff:fe13:2540%fxp0 prefixlen 64 scopeid 0x5(site-local) >>> >>> While we're at it, update the in6.h file to include all scopes >>> in RFC4291. >>> >>> Look OK? Anyone up for applying these? >> >> This kind of output might be cooler? >> >> inet6 fe80::290:27ff:fe13:2540%fxp0 prefixlen 64 scope site >> > > Yes, I would want something like this too, we don't really need the numbers. I'd go with something number+space+text as that going to least likely break existing scripts (unless they match on line end;). Another thing I am worried about is the output getting more likely >80 chars which is a bit of a pain. -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT Software is harder than hardware so better get it right the first time. From owner-freebsd-net@FreeBSD.ORG Tue Jan 8 22:47:17 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 952EC16A421; Tue, 8 Jan 2008 22:47:17 +0000 (UTC) (envelope-from Jinmei_Tatuya@isc.org) Received: from mon.jinmei.org (unknown [IPv6:2001:4f8:3:36::162]) by mx1.freebsd.org (Postfix) with ESMTP id 98A1B13C43E; Tue, 8 Jan 2008 22:47:17 +0000 (UTC) (envelope-from Jinmei_Tatuya@isc.org) Received: from dhcp-wi-27.sql1.isc.org (dhcp-wi-27.sql1.isc.org [204.152.189.27]) by mon.jinmei.org (Postfix) with ESMTP id 73E9433C25; Wed, 9 Jan 2008 07:47:17 +0900 (JST) Date: Tue, 08 Jan 2008 14:47:17 -0800 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Michael Tuexen In-Reply-To: <0AA9B264-8935-41E9-AC26-102ED6EE253C@lurchi.franken.de> References: <20080104215626.GA88922@goku.pumpky.net> <0AA9B264-8935-41E9-AC26-102ED6EE253C@lurchi.franken.de> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.0 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Mailman-Approved-At: Tue, 08 Jan 2008 22:54:24 +0000 Cc: "Crist J. Clark" , net@freebsd.org Subject: Re: Text for IPv6 Scope X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2008 22:47:17 -0000 At Sat, 5 Jan 2008 12:52:53 +0100, Michael Tuexen wrote: > aren't site-local IPv6 addresses depreceated (RFC 3879)? So shouldn't > the site-local stuff be removed? RFC3879 only deprecates site-local *unicast* addresses; the notion of "site-local" is still valid for multicast addresses (this is a very common misunderstanding about the "deprecation of site-local"). So we should not remove IPV6_ADDR_SCOPE_SITELOCAL from in6.h. Going back to the original question of this thread, I don't have a strong opinion on whether it's a good idea to show scope types in alphabets. But I'd point out that it might break convention (further) that an output of ifconfig can often be used as an input, too. For example, if we have: ed0: flags=8843 mtu 1500 inet6 fe80::2c4:77ff:fea1:55ed%ed0 prefixlen 64 scopeid 0x1 inet 10.211.55.11 netmask 0xffffff00 broadcast 10.211.55.255 inet6 2001:db8::1234 prefixlen 64 ether 00:c4:77:a1:55:ed media: Ethernet autoselect (10baseT/UTP) then we could do # ifconfig ed0 `ifconfig ed0 | grep 'inet6 2001'` Adding the scope type text would break this convention (at least if implemented naively). I don't know whether people care about this much, though. Also, we've actually already broken this convention by showing 'scoped 0xXX' for link-locals, so it may not be a big deal any more. BTW, the patch in its current form is not correct in that "scopeid" is the scope index of a specific type of scope, not the "scope type" (link-local, site-local, etc). --- JINMEI, Tatuya Internet Systems Consortium, Inc. From owner-freebsd-net@FreeBSD.ORG Tue Jan 8 23:00:24 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05BA716A46B for ; Tue, 8 Jan 2008 23:00:24 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outG.internet-mail-service.net (outG.internet-mail-service.net [216.240.47.230]) by mx1.freebsd.org (Postfix) with ESMTP id E52D513C45B for ; Tue, 8 Jan 2008 23:00:23 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Tue, 08 Jan 2008 15:00:23 -0800 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 2DBD0126E61; Tue, 8 Jan 2008 15:00:22 -0800 (PST) Message-ID: <4784009B.6030601@elischer.org> Date: Tue, 08 Jan 2008 15:00:43 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Andre Oppermann References: <4772F123.5030303@elischer.org> <477416CC.4090906@elischer.org> <477D2EF3.2060909@elischer.org> <4780E5E7.2070202@FreeBSD.org><4781197F.1000105@elischer.org> <47814AF0.9070509@freebsd.org> <305C539CA2F86249BF51CDCE8996AFF4096E12A7@bcs-mail2.internal.cacheflow.com> <4783F398.801@freebsd.org> In-Reply-To: <4783F398.801@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Li, Qing" , Qing Li , FreeBSD Net , arch@freebsd.org, Ivo Vachkov , Robert Watson , Vadim Goncharov , "Bruce M. Simpson" Subject: Re: resend: multiple routing table roadmap (format fix) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2008 23:00:24 -0000 Andre Oppermann wrote: > > People with the ultimate need for speed have to maintain their own > trees anyway (Bluecoat, Juniper, Sandvine, Isilon,...) and can afford > to cut some more corners anyway. We are trying to get away from that. We are trying to get more BACK from those companies. From owner-freebsd-net@FreeBSD.ORG Wed Jan 9 02:01:37 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA17A16A419; Wed, 9 Jan 2008 02:01:37 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by mx1.freebsd.org (Postfix) with ESMTP id 726CD13C442; Wed, 9 Jan 2008 02:01:37 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 0D70C85FC3; Tue, 8 Jan 2008 21:01:37 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute2.internal (MEProxy); Tue, 08 Jan 2008 21:01:37 -0500 X-Sasl-enc: RjBDbkTnj0Bc3CtIiwbJbcM1ruLxeQ/GCXz9mIcFutFw 1199844096 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id E34101626D; Tue, 8 Jan 2008 21:01:35 -0500 (EST) Message-ID: <47842AFE.8070504@FreeBSD.org> Date: Wed, 09 Jan 2008 02:01:34 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.6 (X11/20070928) MIME-Version: 1.0 To: Vadim Goncharov References: <4772F123.5030303@elischer.org> <477416CC.4090906@elischer.org> <477D2EF3.2060909@elischer.org> <4780E5E7.2070202@FreeBSD.org> <4781197F.1000105@elischer.org> <47814AF0.9070509@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Andre Oppermann , Qing Li , FreeBSD Net , arch@freebsd.org, Ivo Vachkov , Robert Watson , Julian Elischer Subject: Re: resend: multiple routing table roadmap (format fix) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2008 02:01:37 -0000 Vadim Goncharov wrote: > Compare it with a scheme where for EVERY forwarded packet, there is a > need for DOUBLE lookup - after a routing one, do another in L2 table. ARP lookups will generally use a cheap hash once split. What's the problem? The PATRICIA lookups are more expensive, to be sure. Don't forget, though, that with moving L2 info out of PATRICIA, those host routes disappear from the table too, and thus their overhead during the tree walk. rmlocks for L2 and L3 are probably going to be cheaper compared to a global mutex. > > Current routing table implementation, with all disadvantages of > combining L2 and L3, have from the same combinig a one HUGE benefit - > performance. And never, ever, ever, ever even try to split L2 from L3 > with losing that performance - then it should be still never split, > despite all disadvantages, and you'll become an enemy of many, many > users. Especially while caching allows to do things reasonably fast. > I disagree. The architectural benefits of taking ARP cache entries out of the routing table seem quite clear to me. Other implementations have done this and seen it bear fruit, and your argument here sounds like hyperbole rather than cogent and reasoned argument about why this shouldn't be done. If you have grave doubts about this which the rest of us aren't seeing, publish benchmarks? One place to start might be to take Qing's code, run with it, and look seriously at it in a profiler such as Valgrind. But I'm preaching to the choir here... Cheers BMS From owner-freebsd-net@FreeBSD.ORG Wed Jan 9 02:06:05 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D45B416A4A0; Wed, 9 Jan 2008 02:06:05 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by mx1.freebsd.org (Postfix) with ESMTP id 9958213C447; Wed, 9 Jan 2008 02:06:05 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 3DE3985F13; Tue, 8 Jan 2008 21:06:05 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Tue, 08 Jan 2008 21:06:05 -0500 X-Sasl-enc: k+UHqlKM+pfnJTAa3FSJHjNndXK9hHQikPWGoKt6x914 1199844343 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 316D2C34C; Tue, 8 Jan 2008 21:05:42 -0500 (EST) Message-ID: <47842BF5.8060907@FreeBSD.org> Date: Wed, 09 Jan 2008 02:05:41 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.6 (X11/20070928) MIME-Version: 1.0 To: Julian Elischer References: <4772F123.5030303@elischer.org> <477416CC.4090906@elischer.org> <477D2EF3.2060909@elischer.org> <4780E5E7.2070202@FreeBSD.org><4781197F.1000105@elischer.org> <47814AF0.9070509@freebsd.org> <305C539CA2F86249BF51CDCE8996AFF4096E12A7@bcs-mail2.internal.cacheflow.com> <4783F398.801@freebsd.org> <4784009B.6030601@elischer.org> In-Reply-To: <4784009B.6030601@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Li, Qing" , Andre Oppermann , Qing Li , FreeBSD Net , arch@freebsd.org, Ivo Vachkov , Robert Watson , Vadim Goncharov Subject: Re: resend: multiple routing table roadmap (format fix) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2008 02:06:05 -0000 Julian Elischer wrote: > Andre Oppermann wrote: >> >> People with the ultimate need for speed have to maintain their own >> trees anyway (Bluecoat, Juniper, Sandvine, Isilon,...) and can afford >> to cut some more corners anyway. > > We are trying to get away from that. We are trying to get more BACK > from those companies. > I know I keep rattling my sabre about co-operative development in "that" IRC channel. The IP stack stuff everyone is looking at right now is just one example of the kind of development which organisations are normally not prepared to sponsor other than in the context of their own projects -- which is fair enough, they are, after all, acting in their own interests, even though we all stand to gain more from mutualism. The weevil is eating away at the apple from the inside, the question is, who's going to tell it like it is -- and who's actually going to do something about it? Hint: The grass is not necessarily greener on the Linux side of the fence. cheers BMS From owner-freebsd-net@FreeBSD.ORG Wed Jan 9 02:09:25 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E48716A419 for ; Wed, 9 Jan 2008 02:09:25 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by mx1.freebsd.org (Postfix) with ESMTP id E76E213C458 for ; Wed, 9 Jan 2008 02:09:24 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 99FDE86403; Tue, 8 Jan 2008 21:09:24 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute2.internal (MEProxy); Tue, 08 Jan 2008 21:09:24 -0500 X-Sasl-enc: jm9l3NTFUyidhhePOv5Om7nLonB4UQ2TkRU2sKBxvCRC 1199844564 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 2E87D2993C; Tue, 8 Jan 2008 21:09:24 -0500 (EST) Message-ID: <47842CD3.4050007@FreeBSD.org> Date: Wed, 09 Jan 2008 02:09:23 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.6 (X11/20070928) MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <20080104215626.GA88922@goku.pumpky.net> <477F674F.7020706@FreeBSD.org> <864pdongvk.wl%rpaulo@fnop.net> <20080108220558.L36482@maildrop.int.zabbadoz.net> In-Reply-To: <20080108220558.L36482@maildrop.int.zabbadoz.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: Text for IPv6 Scope X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2008 02:09:25 -0000 Bjoern A. Zeeb wrote: > I'd go with something number+space+text as that going to least likely > break existing scripts (unless they match on line end;). > > Another thing I am worried about is the output getting more likely 80 > chars which is a bit of a pain. Drop 'prefixlen' and use / instead: inet6 fe80::290:27ff:fe13:2540%fxp0/64 scope site From owner-freebsd-net@FreeBSD.ORG Wed Jan 9 02:41:52 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 210DB16A419 for ; Wed, 9 Jan 2008 02:41:52 +0000 (UTC) (envelope-from toasty@dragondata.com) Received: from tokyo01.jp.mail.your.org (tokyo01.jp.mail.your.org [204.9.54.5]) by mx1.freebsd.org (Postfix) with ESMTP id DF96B13C46A for ; Wed, 9 Jan 2008 02:41:51 +0000 (UTC) (envelope-from toasty@dragondata.com) Received: from mail.your.org (server3-a.your.org [64.202.112.67]) by tokyo01.jp.mail.your.org (Postfix) with ESMTP id 0EE372AD5730 for ; Wed, 9 Jan 2008 02:08:48 +0000 (UTC) Received: from pool014.dhcp.your.org (pool014.dhcp.your.org [69.31.99.14]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.your.org (Postfix) with ESMTP id 56343A0A44E for ; Wed, 9 Jan 2008 02:08:47 +0000 (UTC) Message-Id: From: Kevin Day To: net@freebsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Tue, 8 Jan 2008 20:07:59 -0600 X-Mailer: Apple Mail (2.915) Cc: Subject: route(8) sendpipe/recvpipe not working? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2008 02:41:52 -0000 I'm playing with 6.3-RC1 on a test box to see what breaks for us, and so far only one thing seems wrong... If I do: # route add 1.2.3.4/32 2.3.4.5 -sendpipe 131072 add net 1.2.3.4: gateway 2.3.4.5 It seems to work okay, but the "sendpipe" option doesn't seem to have any effect: # route get 1.2.3.4 route to: 1.2.3.4 destination: 1.2.3.4 mask: 255.255.255.255 gateway: 2.3.4.5 interface: em0 flags: recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire 0 0 0 0 0 0 1500 0 Other options (such as -mtu) seem to work okay, but send/recvpipe doesn't. A search shows this was brought up in June of 2006 as well: http://groups.google.com/group/lucky.freebsd.stable/browse_thread/thread/6f0ce6d030137ea5/48b45e884df3779f%2348b45e884df3779f Before I file a PR... is this a bug or are we misunderstanding how it's supposed to work in 6.x now? -- Kevin From owner-freebsd-net@FreeBSD.ORG Wed Jan 9 04:25:30 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6840416A419 for ; Wed, 9 Jan 2008 04:25:30 +0000 (UTC) (envelope-from randy@psg.com) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.freebsd.org (Postfix) with ESMTP id 36FC013C459 for ; Wed, 9 Jan 2008 04:25:30 +0000 (UTC) (envelope-from randy@psg.com) Received: from [202.214.86.183] by rip.psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JCSVN-000Cl8-0V; Wed, 09 Jan 2008 04:25:29 +0000 Message-ID: <47844CA7.3090704@psg.com> Date: Wed, 09 Jan 2008 13:25:11 +0900 From: Randy Bush User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Sam Leffler References: <18299.42791.826406.76763@roam.psg.com> <18302.50925.780884.908062@roam.psg.com> <4783D63A.7060502@errno.com> In-Reply-To: <4783D63A.7060502@errno.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net Subject: Re: ath0 Ierrs X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2008 04:25:30 -0000 >> how do i debug? > athstats cool! # athstats -i ath0 21 data frames received 54431 data frames transmit 3 tx frames with an alternate rate 104704 long on-chip tx retries 22469 tx failed 'cuz too many retries 54M current transmit rate 35362 tx management frames 3 tx frames discarded prior to association 19063 tx frames with no ack marked 17 tx frames with short preamble 52139519 rx failed 'cuz of bad CRC -- someone else on channel? 72800113 rx failed 'cuz of PHY err -- ?? 23844342 OFDM timing 48951732 CCK timing 4039 CCK restart 3575252 beacons transmitted 12228 periodic calibrations 2 rfgain value change 20 rssi of last ack 9 avg recv rssi -96 rx noise floor 2 cabq frames transmitted 83 switched default/rx antenna Antenna profile: [1] tx 21603 rx 422493 [2] tx 10360 rx 12 i did check the other day, and ath0 was on chan 11 and nearest was 6. bit things go up and down a lot here in the center of tokyo. though the others are all weak signals, and encrypted. next whack with clue bat, please? randy From owner-freebsd-net@FreeBSD.ORG Wed Jan 9 04:42:12 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2937B16A417 for ; Wed, 9 Jan 2008 04:42:12 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id E27A813C4D1 for ; Wed, 9 Jan 2008 04:42:11 +0000 (UTC) (envelope-from sam@errno.com) Received: from Macintosh-2.local ([10.0.0.196]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id m094gBuY087625 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Jan 2008 20:42:11 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <478450A3.1080507@errno.com> Date: Tue, 08 Jan 2008 20:42:11 -0800 From: Sam Leffler Organization: Errno Consulting User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Randy Bush References: <18299.42791.826406.76763@roam.psg.com> <18302.50925.780884.908062@roam.psg.com> <4783D63A.7060502@errno.com> <47844CA7.3090704@psg.com> In-Reply-To: <47844CA7.3090704@psg.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-sonic.net-Metrics: ebb.errno.com; whitelist Cc: FreeBSD Net Subject: Re: ath0 Ierrs X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2008 04:42:12 -0000 Randy Bush wrote: >>> how do i debug? >> athstats > > cool! > > # athstats -i ath0 > 21 data frames received > 54431 data frames transmit > 3 tx frames with an alternate rate > 104704 long on-chip tx retries > 22469 tx failed 'cuz too many retries > 54M current transmit rate > 35362 tx management frames > 3 tx frames discarded prior to association > 19063 tx frames with no ack marked > 17 tx frames with short preamble > 52139519 rx failed 'cuz of bad CRC -- someone else on channel? This number is huge and indicates either noise on the channel or, more likely, an issue in your card/antennna cabling. > 72800113 rx failed 'cuz of PHY err -- ?? > 23844342 OFDM timing > 48951732 CCK timing > 4039 CCK restart These are likely the same issue. > 3575252 beacons transmitted > 12228 periodic calibrations > 2 rfgain value change > 20 rssi of last ack > 9 avg recv rssi > -96 rx noise floor > 2 cabq frames transmitted > 83 switched default/rx antenna > Antenna profile: > [1] tx 21603 rx 422493 > [2] tx 10360 rx 12 > > i did check the other day, and ath0 was on chan 11 and nearest was 6. > bit things go up and down a lot here in the center of tokyo. though the > others are all weak signals, and encrypted. > > next whack with clue bat, please? I'd check physical setup and/or look for noise in your environment (is there a disk in this machine?) Basically isolate potential noise sources to rule out external causes. With zero info to go on everything is a guess. Sam From owner-freebsd-net@FreeBSD.ORG Wed Jan 9 11:02:27 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 75A7B16A420 for ; Wed, 9 Jan 2008 11:02:27 +0000 (UTC) (envelope-from Patrick.Oonk@ictu.nl) Received: from ms01.ictu.nl (ms01.ictu.nl [193.172.9.10]) by mx1.freebsd.org (Postfix) with ESMTP id 3359613C45B for ; Wed, 9 Jan 2008 11:02:27 +0000 (UTC) (envelope-from Patrick.Oonk@ictu.nl) X-ASG-Debug-ID: 1199875460-6cc700ab0000-QdxwpM X-Barracuda-URL: http://10.19.5.3:8000/cgi-bin/mark.cgi Received: from igw01.dh24.ictu.nl (localhost [127.0.0.1]) by ms01.ictu.nl (Spam Firewall) with ESMTP id CBA6521712 for ; Wed, 9 Jan 2008 11:44:20 +0100 (CET) Received: from igw01.dh24.ictu.nl ([10.10.2.3]) by ms01.ictu.nl with ESMTP id VgBkvtDmCrmKvBLv for ; Wed, 09 Jan 2008 11:44:20 +0100 (CET) X-ASG-Whitelist: Sender X-ASG-Whitelist: Client Received: from [10.10.10.56] ([10.10.10.56]) by igw01.dh24.ictu.nl with Microsoft SMTPSVC(5.0.2195.6713); Wed, 9 Jan 2008 11:44:20 +0100 Mime-Version: 1.0 (Apple Message framework v753) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: freebsd-net@freebsd.org From: Patrick Oonk X-ASG-Orig-Subj: NATD problem Date: Wed, 9 Jan 2008 11:44:19 +0100 X-Mailer: Apple Mail (2.753) X-OriginalArrivalTime: 09 Jan 2008 10:44:20.0809 (UTC) FILETIME=[97680B90:01C852AC] X-Barracuda-Connect: UNKNOWN[10.10.2.3] X-Barracuda-Start-Time: 1199875460 X-Barracuda-Virus-Scanned: by ms01.ictu.nl at ictu.nl Subject: NATD problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2008 11:02:27 -0000 Dear list users, I have the following problem: I have for example two static nat hosts: host A -redirect_address 192.168.0.2 128.1.1.2 Host B -redirect_address 192.168.0.3 128.1.1.3 I have a webserver running on host A. When I try to reach either host A the 'outside', that works fine. When I try to reach host A from host B on it's external address, i.e. when I try to reach port 80 on 128.1.1.2 with source address 192.168.0.3, I get 'connection refused'. Do I have to do anything special to make this possible? thanks Patrick From owner-freebsd-net@FreeBSD.ORG Wed Jan 9 12:38:07 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D4A816A418 for ; Wed, 9 Jan 2008 12:38:07 +0000 (UTC) (envelope-from cjeker@diehard.n-r-g.com) Received: from diehard.n-r-g.com (diehard.n-r-g.com [62.48.3.9]) by mx1.freebsd.org (Postfix) with ESMTP id 9C29413C4E5 for ; Wed, 9 Jan 2008 12:38:06 +0000 (UTC) (envelope-from cjeker@diehard.n-r-g.com) Received: (qmail 7339 invoked by uid 1001); 9 Jan 2008 12:11:24 -0000 Date: Wed, 9 Jan 2008 13:11:24 +0100 From: Claudio Jeker To: freebsd-net@freebsd.org, net@freebsd.org Message-ID: <20080109121124.GC15097@diehard.n-r-g.com> Mail-Followup-To: Claudio Jeker , freebsd-net@freebsd.org, net@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.16 (2007-06-09) Cc: Subject: Re: route(8) sendpipe/recvpipe not working? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2008 12:38:07 -0000 On Tue, Jan 08, 2008 at 08:07:59PM -0600, Kevin Day wrote: > > I'm playing with 6.3-RC1 on a test box to see what breaks for us, and so > far only one thing seems wrong... > > If I do: > > # route add 1.2.3.4/32 2.3.4.5 -sendpipe 131072 > add net 1.2.3.4: gateway 2.3.4.5 > > It seems to work okay, but the "sendpipe" option doesn't seem to have any > effect: > > # route get 1.2.3.4 > route to: 1.2.3.4 > destination: 1.2.3.4 > mask: 255.255.255.255 > gateway: 2.3.4.5 > interface: em0 > flags: > recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu > expire > 0 0 0 0 0 0 1500 > 0 > > > Other options (such as -mtu) seem to work okay, but send/recvpipe doesn't. > A search shows this was brought up in June of 2006 as well: > recvpipe, sendpipe, ssthresh, rtt, rttvar have been removed from the kernel routing table long time ago. -- :wq Claudio From owner-freebsd-net@FreeBSD.ORG Wed Jan 9 12:38:07 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3EB8816A421 for ; Wed, 9 Jan 2008 12:38:07 +0000 (UTC) (envelope-from cjeker@diehard.n-r-g.com) Received: from diehard.n-r-g.com (diehard.n-r-g.com [62.48.3.9]) by mx1.freebsd.org (Postfix) with ESMTP id 9EC1E13C4E7 for ; Wed, 9 Jan 2008 12:38:06 +0000 (UTC) (envelope-from cjeker@diehard.n-r-g.com) Received: (qmail 7339 invoked by uid 1001); 9 Jan 2008 12:11:24 -0000 Date: Wed, 9 Jan 2008 13:11:24 +0100 From: Claudio Jeker To: freebsd-net@freebsd.org, net@freebsd.org Message-ID: <20080109121124.GC15097@diehard.n-r-g.com> Mail-Followup-To: Claudio Jeker , freebsd-net@freebsd.org, net@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.16 (2007-06-09) Cc: Subject: Re: route(8) sendpipe/recvpipe not working? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2008 12:38:07 -0000 On Tue, Jan 08, 2008 at 08:07:59PM -0600, Kevin Day wrote: > > I'm playing with 6.3-RC1 on a test box to see what breaks for us, and so > far only one thing seems wrong... > > If I do: > > # route add 1.2.3.4/32 2.3.4.5 -sendpipe 131072 > add net 1.2.3.4: gateway 2.3.4.5 > > It seems to work okay, but the "sendpipe" option doesn't seem to have any > effect: > > # route get 1.2.3.4 > route to: 1.2.3.4 > destination: 1.2.3.4 > mask: 255.255.255.255 > gateway: 2.3.4.5 > interface: em0 > flags: > recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu > expire > 0 0 0 0 0 0 1500 > 0 > > > Other options (such as -mtu) seem to work okay, but send/recvpipe doesn't. > A search shows this was brought up in June of 2006 as well: > recvpipe, sendpipe, ssthresh, rtt, rttvar have been removed from the kernel routing table long time ago. -- :wq Claudio From owner-freebsd-net@FreeBSD.ORG Wed Jan 9 12:40:03 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19D4E16A477 for ; Wed, 9 Jan 2008 12:40:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id DFFDA13C45A for ; Wed, 9 Jan 2008 12:40:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m09Ce2eJ031911 for ; Wed, 9 Jan 2008 12:40:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m09Ce2Fb031910; Wed, 9 Jan 2008 12:40:02 GMT (envelope-from gnats) Date: Wed, 9 Jan 2008 12:40:02 GMT Message-Id: <200801091240.m09Ce2Fb031910@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Vladimir Ivanov Cc: Subject: Re: kern/117043: [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM Checksum is Not Valid X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Vladimir Ivanov List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2008 12:40:03 -0000 The following reply was made to PR kern/117043; it has been noted by GNATS. From: Vladimir Ivanov To: bug-followup@FreeBSD.org, wishmaster@velnet.ru Cc: Subject: Re: kern/117043: [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM Checksum is Not Valid Date: Wed, 09 Jan 2008 15:09:54 +0300 Do you've IPMI board? WBR, Vladimir From owner-freebsd-net@FreeBSD.ORG Wed Jan 9 17:40:03 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C3E016A420 for ; Wed, 9 Jan 2008 17:40:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id EF94C13C469 for ; Wed, 9 Jan 2008 17:40:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m09He2cX039965 for ; Wed, 9 Jan 2008 17:40:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m09He2v7039964; Wed, 9 Jan 2008 17:40:02 GMT (envelope-from gnats) Date: Wed, 9 Jan 2008 17:40:02 GMT Message-Id: <200801091740.m09He2v7039964@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Wishmaster Cc: Subject: Re[2]: kern/117043: [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM Checksum is Not Valid X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Wishmaster List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2008 17:40:03 -0000 The following reply was made to PR kern/117043; it has been noted by GNATS. From: Wishmaster To: bug-followup@FreeBSD.org, wawa@yandex-team.ru Cc: Subject: Re[2]: kern/117043: [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM Checksum is Not Valid Date: Wed, 9 Jan 2008 19:31:52 +0300 Hello Vladimir, Wednesday, January 9, 2008, 3:09:54 PM, you wrote: VI> Do you've IPMI board? VI> WBR, VI> Vladimir What do you mean under "IPMI board"? I have server MB Asus P5M2. (http://ru.asus.com/products.aspx?l1=9&l2=39&l3=352&l4=0&model=1396&modelmenu=1) BTW, I've seen the same problem on another motherboards even for socket 478 CPUs. BTW1, There are no problems with the same network card but with the PCI-E 4x slot. I think that the problems locates in PCI-X 64bit bus driver and not in network card hardware or driver. -- Best regards, Wishmaster mailto:wishmaster@velnet.ru From owner-freebsd-net@FreeBSD.ORG Wed Jan 9 18:10:23 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3BD7116A4C8 for ; Wed, 9 Jan 2008 18:10:23 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.181]) by mx1.freebsd.org (Postfix) with ESMTP id 0F22E13C465 for ; Wed, 9 Jan 2008 18:10:22 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so596948waf.3 for ; Wed, 09 Jan 2008 10:10:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=tkr4zMXxOwgODjOP/2t26vi2RD9gOGlRSHkvUWFF8bw=; b=JDKZNijcyTxlyje3RZ3CqhmznsP9rGIglJyzRL0l7nt85yQv3j1SGcQlfoz2gnfyv/0uxOC7YYnwB6pKpNdtIdtiZ7RVYyKtNR99Q1Vz/VldMIgL3IxT4Wj30HUnkH11UcxVICGhhyk76goH66q9FfErxj2/JenpbKPzoVKBMIU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Lra9WoBkUb1PTaC5yDRkUsYKoA8bX+hg/KKQE/xUCKI+EDV+83xltC0GU7cezX9vqY2IgaZai6Di5JimtSykPOWQF6VRO9aS7Qg+aGDoJQIbu2XwJlpvkgMdhVLansWYiEpaVVxBdopLk4zXmrIDBzDUK25sisiDIAGfKpoIBew= Received: by 10.115.108.1 with SMTP id k1mr1106102wam.141.1199902222612; Wed, 09 Jan 2008 10:10:22 -0800 (PST) Received: by 10.114.39.18 with HTTP; Wed, 9 Jan 2008 10:10:22 -0800 (PST) Message-ID: <2a41acea0801091010m34e85406n15ab365fbb9e793e@mail.gmail.com> Date: Wed, 9 Jan 2008 10:10:22 -0800 From: "Jack Vogel" To: Wishmaster In-Reply-To: <200801091740.m09He2v7039964@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200801091740.m09He2v7039964@freefall.freebsd.org> Cc: freebsd-net@freebsd.org Subject: Re: Re[2]: kern/117043: [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM Checksum is Not Valid X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2008 18:10:23 -0000 Get 6.3 RC and then use the eeprom dump ability `sysctl dev.em.X.debug=2` We have lots of these cards and do not see this problem, but this is also a common type card that gets counterfeited and the fakes often have bogus eeproms on them. Its possible there is a real problem lurking here however, can you move the adapter to different systems just to see if the problem happens whereever the card is moved or if its system specific?? Regards, Jack On Jan 9, 2008 9:40 AM, Wishmaster wrote: > The following reply was made to PR kern/117043; it has been noted by GNATS. > > From: Wishmaster > To: bug-followup@FreeBSD.org, wawa@yandex-team.ru > Cc: > Subject: Re[2]: kern/117043: [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM Checksum is Not Valid > Date: Wed, 9 Jan 2008 19:31:52 +0300 > > Hello Vladimir, > > Wednesday, January 9, 2008, 3:09:54 PM, you wrote: > > VI> Do you've IPMI board? > > VI> WBR, > VI> Vladimir > > > What do you mean under "IPMI board"? > > I have server MB Asus P5M2. (http://ru.asus.com/products.aspx?l1=9&l2=39&l3=352&l4=0&model=1396&modelmenu=1) > > BTW, I've seen the same problem on another motherboards even for > socket 478 CPUs. > > BTW1, There are no problems with the same network card but with the PCI-E 4x slot. > I think that the problems locates in PCI-X 64bit bus driver and not in > network card hardware or driver. > > -- > Best regards, > Wishmaster mailto:wishmaster@velnet.ru > > > _______________________________________________ > 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 9 23:30:34 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7ED4A16A418 for ; Wed, 9 Jan 2008 23:30:34 +0000 (UTC) (envelope-from fox@verio.net) Received: from dfw-smtpout2.email.verio.net (dfw-smtpout2.email.verio.net [129.250.36.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5EDD513C447 for ; Wed, 9 Jan 2008 23:30:34 +0000 (UTC) (envelope-from fox@verio.net) Received: from [129.250.36.64] (helo=dfw-mmp4.email.verio.net) by dfw-smtpout2.email.verio.net with esmtp id 1JCjNd-0000dH-EW for freebsd-net@freebsd.org; Wed, 09 Jan 2008 22:26:37 +0000 Received: from [129.250.40.241] (helo=limbo.int.dllstx01.us.it.verio.net) by dfw-mmp4.email.verio.net with esmtp id 1JCjNd-0001wm-Ao for freebsd-net@freebsd.org; Wed, 09 Jan 2008 22:26:37 +0000 Received: by limbo.int.dllstx01.us.it.verio.net (Postfix, from userid 1000) id C945D8E296; Wed, 9 Jan 2008 16:26:34 -0600 (CST) Date: Wed, 9 Jan 2008 16:26:34 -0600 From: David DeSimone To: freebsd-net@freebsd.org Message-ID: <20080109222634.GH17784@verio.net> Mail-Followup-To: freebsd-net@freebsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: Precedence: bulk User-Agent: Mutt/1.5.9i Subject: Re: NATD problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2008 23:30:34 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Patrick Oonk wrote: > > host A > -redirect_address 192.168.0.2 128.1.1.2 > > Host B > -redirect_address 192.168.0.3 128.1.1.3 > > I have a webserver running on host A. > When I try to reach either host A the 'outside', that works fine. > > When I try to reach host A from host B on it's external address, > i.e. when I try to reach port 80 on 128.1.1.2 with source address > 192.168.0.3, I get 'connection refused'. > > Do I have to do anything special to make this possible? This is a classic NAT problem. Picture what happens each step of the way: Packet (src = 192.168.0.3, dst = 128.1.1.2) goes to the firewall, because routing for 128.1.1.2 follows default route to firewall. Firewall applies NAT, so packet is now (src = 192.168.0.3, dst = 192.168.0.2). Firewall routes the packet back to the internal network that it came from. Host A receives packet (src = 192.168.0.3, dst = 192.168.0.2). Host A sends back a reply packet (src = 192.168.0.2, dst = 192.168.0.3). Routing table finds a connected route, so reply goes DIRECTLY to host B over internal network. Firewall does not see reply, so there is no chance to apply reverse NAT. Host B receives packet (src = 192.168.0.2, dst = 192.168.0.3). The packet is unrecognized, however, because the packet that host B originally sent was for (src = 192.168.0.3, dst = 128.1.1.2). Host B sends a RST. Connection fails. The way I have solved this problem in other environments is with "double NAT" where the firewall translates both the Source and Destination IP for internally-receive traffic. The firewall applies the correct destination NAT, but also applies NAT to the source IP, giving its own IP. This causes the web server to reply back to the firewall so that the traffic can be de-NAT'd correctly. However, I am unaware of the ability to perform Double NAT using FreeBSD tools. There is no reason the kernel could not do it; it is just a missing feature in the toolset. Many people argue that Host B should "know" that it should not contact Host A using the external IP. Either a host file, or special internal DNS server, or some other such mechanism should help internal hosts to know how best to contact other internal hosts. - -- David DeSimone == Network Admin == fox@verio.net "This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, dis- tribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free. Thank you." --Lawyer Bot 6000 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFHhUoaFSrKRjX5eCoRAnoUAJ9jv4zBy6MeYXJZQryTi2jIM0yfsACbBs3x EOIg9lwBVJd9EaMCJ/oxFCw= =Y28j -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Thu Jan 10 04:06:42 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5A8916A418; Thu, 10 Jan 2008 04:06:42 +0000 (UTC) (envelope-from lastewart@swin.edu.au) Received: from swin.edu.au (gpo2.cc.swin.edu.au [136.186.1.222]) by mx1.freebsd.org (Postfix) with ESMTP id 7B64F13C459; Thu, 10 Jan 2008 04:06:42 +0000 (UTC) (envelope-from lastewart@swin.edu.au) Received: from [136.186.229.95] (lstewart.caia.swin.edu.au [136.186.229.95]) by swin.edu.au (8.13.6.20060614/8.13.1) with ESMTP id m0A3Cr1l018960; Thu, 10 Jan 2008 14:12:54 +1100 Message-ID: <47858D35.6060006@swin.edu.au> Date: Thu, 10 Jan 2008 14:12:53 +1100 From: Lawrence Stewart User-Agent: Thunderbird 1.5.0.9 (X11/20070123) MIME-Version: 1.0 To: Andre Oppermann References: <20071219123305.Y95322@fledge.watson.org> <47693DBD.6050104@swin.edu.au> <476A45D6.6030305@freebsd.org> In-Reply-To: <476A45D6.6030305@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.1.9 X-Spam-Checker-Version: SpamAssassin 3.1.9 (2007-02-13) on gpo2.cc.swin.edu.au Cc: James Healy , arch@freebsd.org, Robert Watson , net@freebsd.org Subject: Re: Coordinating TCP projects X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2008 04:06:43 -0000 Hi Andre, Andre Oppermann wrote: > Lawrence Stewart wrote: [snip] >> Jim and I recently discussed the idea of implementing autotuning of >> the TCP reassembly queue size based on analysis of some experimental >> work we've been doing. It's a small project, but we feel it would be >> worth implementing. Details follow... >> >> >> Problem description: >> >> Currently, "net.inet.tcp.reass.maxqlen" specifies the maximum number >> of segments that can be held in the reassembly queue for a TCP >> connection. The current default value is 48, which equates to approx. >> 69k of buffer space if MSS = 1448 bytes. This means that if the TCP >> window grows to be more than 48 segments wide, and a packet is lost, >> the receiver will buffer the next 48 segments in the reassembly queue >> and subsequently drop all the remaining segments in the window because >> the reassembly buffer is full i.e. 1 packet loss in the network can >> equate to many packet losses at the receiver because of insufficient >> buffering. This obviously has a negative impact on performance in >> environments where there is non-zero packet loss. >> >> With the addition of automatic socket buffer tuning in FreeBSD 7, the >> ability for the TCP window to grow above 48 segments is going to be >> even more prevalent than it is now, so this issue will continue to >> affect connections to FreeBSD based TCP receivers. >> >> We observed that the socket receive buffer size provides a good >> indication of the expected number of bytes in flight for a connection, >> and can therefore serve as the figure to base the size of the >> reassembly queue on. > > I've got a rewritten and much more efficient tcp_reass() function > in my local tree. I'll import it into Perforce next week with all > the other stuff. You may want to base your auto-sizing work on it. > The only missing parts are some statistics gathering. > Where abouts is this code? A cursory browse through the Perforce web front-end reveals nothing. We're going to start work on the TCP reassembly queue autotuning patch now and if you think we should base it on your new tcp_reass() we need to have a look at it. Cheers, Lawrence From owner-freebsd-net@FreeBSD.ORG Thu Jan 10 09:12:55 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1822B16A420 for ; Thu, 10 Jan 2008 09:12:55 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 4E2B213C45D for ; Thu, 10 Jan 2008 09:12:53 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 11939 invoked from network); 10 Jan 2008 08:36:46 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 10 Jan 2008 08:36:46 -0000 Message-ID: <4785E19A.2040102@freebsd.org> Date: Thu, 10 Jan 2008 10:12:58 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Lawrence Stewart References: <20071219123305.Y95322@fledge.watson.org> <47693DBD.6050104@swin.edu.au> <476A45D6.6030305@freebsd.org> <47858D35.6060006@swin.edu.au> In-Reply-To: <47858D35.6060006@swin.edu.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: James Healy , arch@freebsd.org, Robert Watson , net@freebsd.org Subject: Re: Coordinating TCP projects X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2008 09:12:55 -0000 Lawrence Stewart wrote: > Hi Andre, > > Andre Oppermann wrote: >> Lawrence Stewart wrote: > > [snip] > >>> Jim and I recently discussed the idea of implementing autotuning of >>> the TCP reassembly queue size based on analysis of some experimental >>> work we've been doing. It's a small project, but we feel it would be >>> worth implementing. Details follow... >>> >>> >>> Problem description: >>> >>> Currently, "net.inet.tcp.reass.maxqlen" specifies the maximum number >>> of segments that can be held in the reassembly queue for a TCP >>> connection. The current default value is 48, which equates to approx. >>> 69k of buffer space if MSS = 1448 bytes. This means that if the TCP >>> window grows to be more than 48 segments wide, and a packet is lost, >>> the receiver will buffer the next 48 segments in the reassembly queue >>> and subsequently drop all the remaining segments in the window >>> because the reassembly buffer is full i.e. 1 packet loss in the >>> network can equate to many packet losses at the receiver because of >>> insufficient buffering. This obviously has a negative impact on >>> performance in environments where there is non-zero packet loss. >>> >>> With the addition of automatic socket buffer tuning in FreeBSD 7, the >>> ability for the TCP window to grow above 48 segments is going to be >>> even more prevalent than it is now, so this issue will continue to >>> affect connections to FreeBSD based TCP receivers. >>> >>> We observed that the socket receive buffer size provides a good >>> indication of the expected number of bytes in flight for a >>> connection, and can therefore serve as the figure to base the size of >>> the reassembly queue on. >> >> I've got a rewritten and much more efficient tcp_reass() function >> in my local tree. I'll import it into Perforce next week with all >> the other stuff. You may want to base your auto-sizing work on it. >> The only missing parts are some statistics gathering. >> > > Where abouts is this code? A cursory browse through the Perforce web > front-end reveals nothing. We're going to start work on the TCP > reassembly queue autotuning patch now and if you think we should base it > on your new tcp_reass() we need to have a look at it. I'll put everything into Perforce this evening (European time). Christmas/newyear didn't provide as much spare time as I had hoped. ;-) -- Andre From owner-freebsd-net@FreeBSD.ORG Thu Jan 10 09:20:03 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3EF3716A419 for ; Thu, 10 Jan 2008 09:20:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 0563913C461 for ; Thu, 10 Jan 2008 09:20:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m0A9K2eG091537 for ; Thu, 10 Jan 2008 09:20:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m0A9K2G0091536; Thu, 10 Jan 2008 09:20:02 GMT (envelope-from gnats) Date: Thu, 10 Jan 2008 09:20:02 GMT Message-Id: <200801100920.m0A9K2G0091536@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Vladimir Ivanov Cc: Subject: Re: kern/117043: [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM Checksum is Not Valid X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Vladimir Ivanov List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2008 09:20:03 -0000 The following reply was made to PR kern/117043; it has been noted by GNATS. From: Vladimir Ivanov To: Wishmaster Cc: bug-followup@FreeBSD.org Subject: Re: kern/117043: [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM Checksum is Not Valid Date: Thu, 10 Jan 2008 12:12:36 +0300 Wishmaster wrote: > What do you mean under "IPMI board"? I've seen similar bugs if IPMI lan management has been installed. > > I have server MB Asus P5M2. (http://ru.asus.com/products.aspx?l1=9&l2=39&l3=352&l4=0&model=1396&modelmenu=1) > > BTW, I've seen the same problem on another motherboards even for > socket 478 CPUs. > > BTW1, There are no problems with the same network card but with the PCI-E 4x slot. > I think that the problems locates in PCI-X 64bit bus driver and not in > network card hardware or driver. > From owner-freebsd-net@FreeBSD.ORG Thu Jan 10 15:33:10 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17AE216A469; Thu, 10 Jan 2008 15:33:10 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by mx1.freebsd.org (Postfix) with ESMTP id DF22013C458; Thu, 10 Jan 2008 15:33:09 +0000 (UTC) (envelope-from rrs@cisco.com) X-IronPort-AV: E=Sophos;i="4.24,267,1196668800"; d="scan'208";a="6682633" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 10 Jan 2008 07:05:08 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m0AF58U7013328; Thu, 10 Jan 2008 07:05:08 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id m0AF58tg020190; Thu, 10 Jan 2008 15:05:08 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Jan 2008 07:05:07 -0800 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Jan 2008 07:05:06 -0800 Message-ID: <4786338D.5050801@cisco.com> Date: Thu, 10 Jan 2008 10:02:37 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20070601 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Watson References: <20071219123305.Y95322@fledge.watson.org> In-Reply-To: <20071219123305.Y95322@fledge.watson.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jan 2008 15:05:07.0052 (UTC) FILETIME=[2FB502C0:01C8539A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6785; t=1199977508; x=1200841508; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:=20Randall=20Stewart=20 |Subject:=20Re=3A=20Coordinating=20TCP=20projects |Sender:=20; bh=xASVwf4yxlw0TpW7wsy7fFFUREOxmnZArXsC1tPpVJk=; b=PJTto/Ip0qIWS6nG4SKQ8wHZ8BqoGJ/i/mwo8QwygJHTdjExMa+HxYs7CD 3UH2WOAlaq6v8ENEoa/0/UW2PxoQXyCHeN7f312Th0Ru5M65tuqfke1AzKgg uFOk0RM/cZIQb/njOZ9sD9RKq9ABlh2zjIwJrSypadq0K2evhHx4U=; Authentication-Results: sj-dkim-1; header.From=rrs@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: James Healy , arch@freebsd.org, Lawrence Stewart , net@freebsd.org Subject: Re: Coordinating TCP projects X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2008 15:33:10 -0000 Robert: One thing I would like to point out for one of Lawrence's project is that SCTP is also hanging around in the kernel and as part of one of our URP's (which is also where Lawrence's project came from.. if I remember right)... we added "selectable" congestion control to SCTP.. well it was not really a URP come to think of it.. but what I kept an intern busy doing last summer :-) Now, the SCTP code DID NOT do kernel loadable CC modules like Lawrences... which is cool.. so .. I wonder.. Would it be possible to take what Lawrence did and generalize it so that *ANY* transport could use it.. i.e. both TCP and SCTP. This would yeild an interesting advantage in that any time one added a CC algorithm all transports would have access to them. Not having looked at the patches yet, what may be missing in the TCP code is to select amongst multiple CC algorithms... we actually have this down to the SCTP association level.. So I can in theory have different associations out of the same box using different CC modules... There might be some good ideas we can harvest from both approaches and make available to all transports... Just some thoughts mind you :-) R Robert Watson wrote: > > Dear all, > > It is rapidly becoming clear that quite a few of us have Big Plans for > the TCP implementation over the next 12-18 months. It's important that > we get the plans out on the table now so that everyone working on these > projects is aware of the larger context. This will encourage > collaboration, but also allow us to manage the risks inevitably > associated with having several simultaneous projects going on in a very > complex software base. With that in mind, here are the large projects > I'm currently aware of: > > Project Flag Wavers Status > ------- ----------- ------ > TCP offload Kip Macy Moving to CVS and under > review and testing; one > supporting device driver. > > TCP congestion control Sam Leffler, At least one prototype > Rui Paulo, implementation, to move to p4 > Andre Oppermann, > Kip Macy, > Lawrence Stewart, > James Healy > > TCP overhaul Andre Oppermann Glimmer in eye, to move to > p4. > > TCP lock granularity/ Robert Watson Glimmer in eye, to occur in > increased parallelism p4. > > TCP timer unification Andre Oppermann, Previously committed, and to > Mike Silbersack be reintroduced via p4. > > Monitoring ABI cleanup Robert Watson Glimmer in eye, to occur in > p4. > > Looking at the above, it sounds like a massive amount of work taking > place, so we will need to coordinate carefully. I'd like to encourage > people to avoid creating unnecessary dependencies between changes, and > to be especially careful in coordinating potentially MFCable changes. > There are (at least) two conflicting scheduling desires in play here: > > - A desire to merge MFCable changes early, so that they aren't entangled > with > un-mergeable changes. This will simplify merging and also maximize the > extent to which testing in HEAD will apply to them once merged to > RELENG_7. > > - A desire to merge large-scale infrastructural changes early so that > they see > the greatest exposure, and so that they can be introduced > incrementally over > a longer period of time to shake each out. > > Both of these are valid perspectives, and will need to be balanced. I > have a few questions, then, for people involved in these or other projects: > > (0) Is your project in the above list? If not, could you send out a reply > talking a bit about the project, who's involved, where it's taking > place, > etc. > > (1) What is your availability to shepherd the project through its entire > cycle, including early prototyping, design review, development, > implementation review, testing, and the inevitable long debugging tail > that all TCP projects have. > > (2) When do you think your implementation will reach a prototype phase > appropriate for an expanded circle of reviewers? When do you think it > might be ready for commit? Keep in mind that we're now a month or > so into > the 18-month cycle for 8.0, and that all serious TCP work should be > completed at least six months before the end of the cycle. > > (3) What potential interactions of note exist between your project and the > others being planned. Are there explicit dependencies? > > (4) Do you anticipate an MFC cycle for your work to RELENG_7? > > I'd like for us to create a wiki page tracking these various projects, > and pointing at per-project resources. Once the discussion has settled > a bit, I can take responsibility for creating such a page, but will need > everyone involved to help maintain it, as well as to maintain pages (on > the wiki or elsewhere) regarding the status of the projects. I think it > also makes a lot of sense for participants in the projects to send > occasional updates and reports to net@/arch@ in order to keep people who > can't track things day-to-date in the loop, and to invite review. > > At the end of the day, we must be clear: the only way even a fraction of > these projects can happen in time for 8.0 is if there is careful > planning, coordination, and exception care taken in the review and > testing of the changes. We cannot have the 8.0 release cycle put at > risk the way the 7.0 cycle was due to inadequately reviwed and tested > patches entering the tree under the assumption that problems would > somehow be magically found and fixed before the release by the > relatively small population of -CURRENT users. Experience tells us that > changes must be extensively reviewed and tested before they enter the tree. > > I'm really looking forward to the 8 development cycle, and the work > that's in the pipeline is really very exciting. It will take quite a > bit of dedication to make it all happen, but if even only a small part > of it happens, it will still be very good news. > > Robert N M Watson > Computer Laboratory > University of Cambridge > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 803-317-4952 (cell) From owner-freebsd-net@FreeBSD.ORG Thu Jan 10 20:56:17 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A656716A418 for ; Thu, 10 Jan 2008 20:56:17 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.186]) by mx1.freebsd.org (Postfix) with ESMTP id 6BD2513C459 for ; Thu, 10 Jan 2008 20:56:17 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: by rv-out-0910.google.com with SMTP id l15so822210rvb.43 for ; Thu, 10 Jan 2008 12:56:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:mime-version:content-type:x-google-sender-auth; bh=Vep0GEMD1+xJVs/66MiCuLs1u9grtdCtSl9Yka49uI8=; b=IG4AGk3mFdE7zFAzq4TpsYSV+rNfWS71knUvTYrP8/sNH7UM3jC+At0gL7Wmw4GYJu2XrK8wMRbGWgx1vwcm/AAW0ce/2oBf7Rte2c9mrqc+YNMs1OtN8uLT14WZBSD61+MxW4l3TLEIvxGrtpprVKwN4O5VK/DDlLQScVgv/Sw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:mime-version:content-type:x-google-sender-auth; b=qfyqgywBWKenSQPMD9VIKXQZXG7yrlaJ0iiqwZ35FNMOGdji+44LI3Xg7wzaLJBcd1b+XLh26rJrrRXiJgKpKgY6brUz5AUEBT4GmV6miJNKWR6GgaynHxGb9gU6JA006CwZQBzT56WwkQXgjXfFdjGoan12l3LoddJtBaaqIDA= Received: by 10.140.135.20 with SMTP id i20mr1506905rvd.146.1199998576771; Thu, 10 Jan 2008 12:56:16 -0800 (PST) Received: by 10.141.170.18 with HTTP; Thu, 10 Jan 2008 12:56:16 -0800 (PST) Message-ID: <2e77fc10801101256o51705240t44e87f32c8e10998@mail.gmail.com> Date: Thu, 10 Jan 2008 22:56:16 +0200 From: "Niki Denev" Sender: ndenev@gmail.com To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_34126_21825712.1199998576774" X-Google-Sender-Auth: 534b50b3ac5c4eb1 Cc: thompsa@freebsd.org Subject: [PATCH] [bin/119542] netstat prints incorrectly host routes on bridge interfaces X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2008 20:56:17 -0000 ------=_Part_34126_21825712.1199998576774 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, As mentioned in the PR : http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/119542 netstat needs a little fix to print correctly host routes on bridge interfaces. The attached patch in the PR and here fixes the problem. Regards, Niki ------=_Part_34126_21825712.1199998576774 Content-Type: text/x-patch; name=netstat-bridge_l2_route_fix.patch Content-Transfer-Encoding: base64 X-Attachment-Id: f_fb9s1cxj0 Content-Disposition: attachment; filename=netstat-bridge_l2_route_fix.patch LS0tIHVzci5iaW4vbmV0c3RhdC9yb3V0ZS5jLm9yaWcJMjAwOC0wMS0xMSAwNDoxNDo1NC4wMDAw MDAwMDAgKzAwMDAKKysrIHVzci5iaW4vbmV0c3RhdC9yb3V0ZS5jCTIwMDgtMDEtMTEgMDQ6MTU6 NTUuMDAwMDAwMDAwICswMDAwCkBAIC02NjAsNiArNjYwLDcgQEAKIAogCQkJY2FzZSBJRlRfRVRI RVI6CiAJCQljYXNlIElGVF9MMlZMQU46CisJCQljYXNlIElGVF9CUklER0U6CiAJCQkJaWYgKHNk bC0+c2RsX2FsZW4gPT0gRVRIRVJfQUREUl9MRU4pIHsKIAkJCQkJY3AgPSBldGhlcl9udG9hKChz dHJ1Y3QgZXRoZXJfYWRkciAqKQogCQkJCQkgICAgKHNkbC0+c2RsX2RhdGEgKyBzZGwtPnNkbF9u bGVuKSk7Cg== ------=_Part_34126_21825712.1199998576774-- From owner-freebsd-net@FreeBSD.ORG Thu Jan 10 23:25:35 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F3F1216A419 for ; Thu, 10 Jan 2008 23:25:34 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.177]) by mx1.freebsd.org (Postfix) with ESMTP id E22E913C4E5 for ; Thu, 10 Jan 2008 23:25:34 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so1474600waf.3 for ; Thu, 10 Jan 2008 15:25:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=HWsKAumDoNRzjvygoNoi2AGET8UDaW8Ctaof99Ixyac=; b=XLwM5CYP2Lv2Kr8jD5tIJ3tkqc24HYA+jqUSWKuCiVHAPOsafWBg6FOtwgFN/bL/+hZTcHSBV1kZML9VRjPcVHgpHcpVXM/6Ut6ibYMLmGWPjEDVgeS/urkV7i4yUkVwZE0sCc+4CXoObW9kAJ/TlvB+qLISUsl6v52B/B1DuA0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=P1EH2uYnyGfoHwtptPKf5cDi+/aPieBkCPhHbh4VVLYjwpTNWrcPaeIiPmQw4sW7/qFknw8H5P5CDk34B0aQwEThxqTz0/StsqQi4oiiIJ1Js3hvRwDrc12hHtL221FPYJAoog5ZuYiSz8jeybe1UwBYKOijfkpJXKCYZ/94rTA= Received: by 10.114.61.1 with SMTP id j1mr2882494waa.62.1200005792257; Thu, 10 Jan 2008 14:56:32 -0800 (PST) Received: by 10.114.255.11 with HTTP; Thu, 10 Jan 2008 14:56:32 -0800 (PST) Message-ID: Date: Thu, 10 Jan 2008 14:56:32 -0800 From: "Kip Macy" To: gnn@freebsd.org In-Reply-To: <7ive61uwfm.wl%gnn@neville-neil.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080106124517.G105@fledge.watson.org> <7ive61uwfm.wl%gnn@neville-neil.com> Cc: arch@freebsd.org, Robert Watson , kmacy@freebsd.org, net@freebsd.org Subject: Re: Network device driver KPI/ABI and TOE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2008 23:25:35 -0000 On Jan 10, 2008 2:50 PM, wrote: > At Sun, 6 Jan 2008 13:47:24 +0000 (GMT), > rwatson wrote: > > > > > > There's also the opportunity to think about whether it's possible to > > harden things in such a ways as to not give up our flexibility to > > keep maintaining and improving TCP (and other related subsystems), > > yet improving the quality of life for a third party TOE driver > > maintainer. For example, might we provide accessor routines for > > certain data structures, or attempt to structure things to hide more > > of TCP locking from a TOE implementation? Should we suggest that > > non-native TOE implementations rely less on our TCP code and provide > > there own where the hardware doesn't provide a complete > > implementation, in order to avoid building dependency on things that > > we know will change? > > > > Given the intimacy that I just perused in the code, basically the > driver knows a lot about internal TCP data structures, I think we need > to think about a kernel KPI just for these things. I'm not very happy > that there are things like cxgb_tcp_ctlinput() although I do know that > cleaning that kind of thing up and making a better KPI will be hard. Although you are correct in the need for a more thought out KPI, that is actually not a good example. Although the way it is currently implemented is not multi-TOE friendly tcp_ctlinput is the correct way to extend socket options. A better example is the way it needs to know the specifics of not only the tcpcb, but the inpcb, and parts of the socket as well. By extension it needs to understand the subtleties of inpcb and pcbinfo locking. This is, needless to say, quite fragile. -Kip From owner-freebsd-net@FreeBSD.ORG Thu Jan 10 23:34:32 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1421D16A417 for ; Thu, 10 Jan 2008 23:34:32 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from outbound0.mx.meer.net (outbound0.mx.meer.net [209.157.153.23]) by mx1.freebsd.org (Postfix) with ESMTP id 1416213C465 for ; Thu, 10 Jan 2008 23:34:32 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by outbound0.mx.meer.net (8.12.10/8.12.6) with ESMTP id m0AMos7T098964; Thu, 10 Jan 2008 14:50:55 -0800 (PST) (envelope-from gnn@neville-neil.com) Received: from mail2.meer.net (mail2.meer.net [64.13.141.16]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id m0AMosra024013; Thu, 10 Jan 2008 14:50:54 -0800 (PST) (envelope-from gnn@neville-neil.com) Received: from gnnbsd.hudson-trading.com.neville-neil.com ([66.150.84.1]) (authenticated bits=0) by mail2.meer.net (8.14.1/8.14.1) with ESMTP id m0AMosoP032324; Thu, 10 Jan 2008 14:50:54 -0800 (PST) (envelope-from gnn@neville-neil.com) Date: Thu, 10 Jan 2008 17:50:53 -0500 Message-ID: <7ive61uwfm.wl%gnn@neville-neil.com> From: gnn@freebsd.org To: Robert Watson In-Reply-To: <20080106124517.G105@fledge.watson.org> References: <20080106124517.G105@fledge.watson.org> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/21.3 (amd64--freebsd) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: arch@freebsd.org, kmacy@freebsd.org, net@freebsd.org Subject: Re: Network device driver KPI/ABI and TOE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2008 23:34:32 -0000 At Sun, 6 Jan 2008 13:47:24 +0000 (GMT), rwatson wrote: > > > There's also the opportunity to think about whether it's possible to > harden things in such a ways as to not give up our flexibility to > keep maintaining and improving TCP (and other related subsystems), > yet improving the quality of life for a third party TOE driver > maintainer. For example, might we provide accessor routines for > certain data structures, or attempt to structure things to hide more > of TCP locking from a TOE implementation? Should we suggest that > non-native TOE implementations rely less on our TCP code and provide > there own where the hardware doesn't provide a complete > implementation, in order to avoid building dependency on things that > we know will change? > Given the intimacy that I just perused in the code, basically the driver knows a lot about internal TCP data structures, I think we need to think about a kernel KPI just for these things. I'm not very happy that there are things like cxgb_tcp_ctlinput() although I do know that cleaning that kind of thing up and making a better KPI will be hard. Best, George From owner-freebsd-net@FreeBSD.ORG Fri Jan 11 01:24:25 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E30CC16A417; Fri, 11 Jan 2008 01:24:25 +0000 (UTC) (envelope-from lastewart@swin.edu.au) Received: from outbound.icp-qv1-irony-out2.iinet.net.au (outbound.icp-qv1-irony-out2.iinet.net.au [203.59.1.107]) by mx1.freebsd.org (Postfix) with ESMTP id 55CE413C45B; Fri, 11 Jan 2008 01:24:25 +0000 (UTC) (envelope-from lastewart@swin.edu.au) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAPhQhkd8qBDq/2dsb2JhbACpfA X-IronPort-AV: E=Sophos;i="4.24,269,1196607600"; d="scan'208";a="264939163" Received: from unknown (HELO newbox.caia.swin.edu.au) ([124.168.16.234]) by outbound.icp-qv1-irony-out2.iinet.net.au with ESMTP; 11 Jan 2008 10:14:10 +0900 Message-ID: <4786C2DA.3030407@swin.edu.au> Date: Fri, 11 Jan 2008 12:14:02 +1100 From: Lawrence Stewart User-Agent: Thunderbird 2.0.0.4 (X11/20070625) MIME-Version: 1.0 To: Randall Stewart References: <20071219123305.Y95322@fledge.watson.org> <4786338D.5050801@cisco.com> In-Reply-To: <4786338D.5050801@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: James Healy , arch@freebsd.org, Robert Watson , net@freebsd.org Subject: Transport layer congestion control ideas (was Re: Coordinating TCP projects) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2008 01:24:26 -0000 Hi Randall, Comments inline... Randall Stewart wrote: > Robert: > > One thing I would like to point out for one of Lawrence's project > is that SCTP is also hanging around in the kernel and as > part of one of our URP's (which is also where Lawrence's project > came from.. if I remember right)... we added "selectable" > congestion control to SCTP.. well it was not really a URP > come to think of it.. but what I kept an intern busy doing > last summer :-) > > Now, the SCTP code DID NOT do kernel loadable CC modules > like Lawrences... which is cool.. so .. I wonder.. > > Would it be possible to take what Lawrence did and generalize > it so that *ANY* transport could use it.. i.e. both TCP and SCTP. > This would yeild an interesting advantage in that any time one > added a CC algorithm all transports would have access to them. Interesting idea... some thought would be required to figure out how to abstract the differences between transports into a generic set of information passed to a CC algorithm to do its job. Nothing specific comes to me immediately as I'm not familiar enough with the SCTP implementation to identify commonalities relevant to CC off the top of my head, but I suspect it wouldn't be *that* much work. Would require some changes to our current KPI. Not sure what changes to SCTP would be involved. Certainly interested to hear/discuss ideas on this to flesh out whether it's something worth pursuing. > > Not having looked at the patches yet, what may be missing in > the TCP code is to select amongst multiple CC algorithms... we > actually have this down to the SCTP association level.. So I > can in theory have different associations out of the same > box using different CC modules... Our TCP patch currently supports the use of a different CC algo per connection (read: per tcb), and allows selection of a system wide default CC algo via sysctl (which can be used crudely to change algos used by connections at initialisation). Jim and I just finished adding the {set|get}sockopt plumbing 2 days ago that allows overriding the system default CC algo on a TCP socket (both at initialisation and dynamically during use). It'll be in Perforce shortly after a bit more testing. As a first step towards streamlining TCP/SCTP CC interactions, I imagine it would be straight forward enough to generalise the sockopt plumbing a bit more to specifcy a "TRANSPORT_CONGESTION" sockopt instead of the currently used "TCP_CONGESTION" and have your SCTP code also respond to set/gets of this option on SCTP sockets. Given you already have the modular CC capabilities, it should be a minor addition. Happy to send you our patch if you want a squiz at it. > > There might be some good ideas we can harvest from both approaches > and make available to all transports... Too many cool ideas! :) Let the good times (and ideas) roll on. [snip Robert's initial email] Cheers, Lawrence From owner-freebsd-net@FreeBSD.ORG Fri Jan 11 02:19:34 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A06DF16A420 for ; Fri, 11 Jan 2008 02:19:34 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id CCC4A13C458 for ; Fri, 11 Jan 2008 02:19:33 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 56574 invoked from network); 11 Jan 2008 01:43:18 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 11 Jan 2008 01:43:18 -0000 Message-ID: <4786D23A.1080509@freebsd.org> Date: Fri, 11 Jan 2008 03:19:38 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Lawrence Stewart References: <20071219123305.Y95322@fledge.watson.org> <47693DBD.6050104@swin.edu.au> <476A45D6.6030305@freebsd.org> <47858D35.6060006@swin.edu.au> In-Reply-To: <47858D35.6060006@swin.edu.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: James Healy , arch@freebsd.org, Robert Watson , net@freebsd.org Subject: Re: Coordinating TCP projects X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2008 02:19:34 -0000 Lawrence Stewart wrote: >> I've got a rewritten and much more efficient tcp_reass() function >> in my local tree. I'll import it into Perforce next week with all >> the other stuff. You may want to base your auto-sizing work on it. >> The only missing parts are some statistics gathering. >> > > Where abouts is this code? A cursory browse through the Perforce web > front-end reveals nothing. We're going to start work on the TCP > reassembly queue autotuning patch now and if you think we should base it > on your new tcp_reass() we need to have a look at it. The first cut is now at //depot/projects/tcp_reass/ however I made a mistake when creating the branch and now the code is in the same changeset as the branching itself. Doesn't make it easy to do a diff. Have to see how I can fix that. Anyway, have a look and I'm going to finish/fix the code tomorrow evening. -- Andre From owner-freebsd-net@FreeBSD.ORG Fri Jan 11 02:22:56 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9889D16A41A; Fri, 11 Jan 2008 02:22:56 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 841A813C457; Fri, 11 Jan 2008 02:22:56 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m0B2Mu6i013424; Fri, 11 Jan 2008 02:22:56 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m0B2MuXT013420; Fri, 11 Jan 2008 02:22:56 GMT (envelope-from linimon) Date: Fri, 11 Jan 2008 02:22:56 GMT Message-Id: <200801110222.m0B2MuXT013420@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/119548: [pf] [ath] PF Altq with ath hostap problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2008 02:22:56 -0000 Old Synopsis: PF Altq with ath hostap problem New Synopsis: [pf] [ath] PF Altq with ath hostap problem Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Jan 11 02:22:26 UTC 2008 Responsible-Changed-Why: Assign to -net mailing list. http://www.freebsd.org/cgi/query-pr.cgi?pr=119548 From owner-freebsd-net@FreeBSD.ORG Fri Jan 11 12:37:41 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CCF7016A421 for ; Fri, 11 Jan 2008 12:37:41 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by mx1.freebsd.org (Postfix) with ESMTP id 3378813C459 for ; Fri, 11 Jan 2008 12:37:40 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: by py-out-1112.google.com with SMTP id u52so1615685pyb.10 for ; Fri, 11 Jan 2008 04:37:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=5gqjodomhkdc8DhPHNBcWH40s61GPZ55zjMx+by0HXk=; b=ABim2IyO9AVn7iEwClJus/Xd4gBZdYPUb/eCr660hS0fkmjNsZ7kBATjiYc+plSEI/EBfO9jgJr1ivGRh3Nakl/UPpj28isBRxXIDQDTdSif/+kXdVjTqOaYwemEo0gwI6OI8LCywykKOxVlmn0YnjqsSPYMSLK2phAyFrHiw3s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=K2xGL6fPAop2DSm0Pecv/2w6joWtgb+DVgEVmSJnCdADIsq6fwixzaJg12qRzOsGhEHC/sYpwWXBHcO18yf1kxSWx/hZh2EGk5Qw6ZsCDsdkTYi3aACcANC4ZCL6yvsC3BgxjAQa63V4QDZTfKsXOF54wn4fB2bqZK6ySiLnC2Q= Received: by 10.142.49.4 with SMTP id w4mr1569655wfw.204.1200055059737; Fri, 11 Jan 2008 04:37:39 -0800 (PST) Received: by 10.142.162.20 with HTTP; Fri, 11 Jan 2008 04:37:39 -0800 (PST) Message-ID: Date: Fri, 11 Jan 2008 20:37:39 +0800 From: "Sepherosa Ziehau" To: "=?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?=" In-Reply-To: <864pds8idc.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <86ir2hznnd.fsf@ds4.des.no> <86abnpu0wv.fsf@ds4.des.no> <86abnovy4k.fsf@ds4.des.no> <86odc3dlgi.fsf@ds4.des.no> <86lk76c6t5.fsf@ds4.des.no> <864pds8idc.fsf@ds4.des.no> Cc: kevlo@freebsd.org, sam@freebsd.org, current@freebsd.org, net@freebsd.org Subject: Re: if_ral regression X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2008 12:37:41 -0000 On Jan 5, 2008 10:19 PM, Dag-Erling Sm=F8rgrav wrote: > "Sepherosa Ziehau" writes: > > This actually brings up two things: > > 1) I think we should ignore seq in multicast frames; this is permitted = in > > 802.11 standard. In dfly I did that, since one of our users > > encountered a broken commercial AP which is not 802.11e but uses > > different seq for data and beacon. > > 2) TX sequence. I think standards only mention QSTA/nQSTA, but not > > AP. Currently our AP uses per node TX seq, which means beacon's seq > > is difficult to choose, at least for 2560 based ral(4), whose beacons' > > seq need to be set by software. I saw Linksys AP uses one seq for all > > of the frames it sends. Sam, what's you opinion on this? > > > > I think if STA counts ral(4)'s beacon seq, as what we do currently, > > beacon missing will quickly happen since beacons will be discarded > > after first several data frames. > > OK, I *think* I understood most of that. Does this suggest a solution > to you? I will try to get the wlandebug output tonight. I don't know whether you are still interested to track down the wired problem you had experienced. If you have time please try following patches: revert the old patch at your AP side and try this one http://people.freebsd.org/~sephe/rt2560_test.diff1 apply following patch at you STA side http://people.freebsd.org/~sephe/ieee80211_input.c.diff Best Regards, sephe --=20 Live Free or Die From owner-freebsd-net@FreeBSD.ORG Fri Jan 11 12:49:43 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D40A516A419; Fri, 11 Jan 2008 12:49:43 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 7D11E13C442; Fri, 11 Jan 2008 12:49:43 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 0FAB02089; Fri, 11 Jan 2008 13:49:35 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.2/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 7B0FA207E; Fri, 11 Jan 2008 13:49:34 +0100 (CET) Received: by ds4.des.no (Postfix, from userid 1001) id 598C2844AF; Fri, 11 Jan 2008 13:49:34 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "Sepherosa Ziehau" References: <86ir2hznnd.fsf@ds4.des.no> <86abnpu0wv.fsf@ds4.des.no> <86abnovy4k.fsf@ds4.des.no> <86odc3dlgi.fsf@ds4.des.no> <86lk76c6t5.fsf@ds4.des.no> <864pds8idc.fsf@ds4.des.no> Date: Fri, 11 Jan 2008 13:49:34 +0100 In-Reply-To: (Sepherosa Ziehau's message of "Fri\, 11 Jan 2008 20\:37\:39 +0800") Message-ID: <86abncedcx.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: kevlo@freebsd.org, sam@freebsd.org, current@freebsd.org, net@freebsd.org Subject: Re: if_ral regression X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2008 12:49:43 -0000 "Sepherosa Ziehau" writes: > revert the old patch at your AP side and try this one > http://people.freebsd.org/~sephe/rt2560_test.diff1 I will, thanks. > apply following patch at you STA side > http://people.freebsd.org/~sephe/ieee80211_input.c.diff My STA side doesn't run FreeBSD... the only laptop I have that does has a flat battery and I can't find the mains adapter :( DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-net@FreeBSD.ORG Fri Jan 11 14:06:32 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B635916A468 for ; Fri, 11 Jan 2008 14:06:32 +0000 (UTC) (envelope-from nayuhz@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.248]) by mx1.freebsd.org (Postfix) with ESMTP id 5E00E13C46B for ; Fri, 11 Jan 2008 14:06:32 +0000 (UTC) (envelope-from nayuhz@gmail.com) Received: by an-out-0708.google.com with SMTP id c14so301921anc.13 for ; Fri, 11 Jan 2008 06:06:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date:message-id:mime-version:content-type:content-transfer-encoding:x-mailer:thread-index:content-language:x-cr-hashedpuzzle:x-cr-puzzleid; bh=JMAi+sZPgzxwV9uc3McCIoIvNPz4ARYArRGInwomjgQ=; b=ZgbdFzm+i/fNkFfcOPcXe23BxRtluMWJr+O8hkRPFXnvo6qaRauM7E5iEM5lD+7nHKIbbaQzP1+hL1CsiFYYn5AEyf+DQ2PvaY77kyyjnuOvSK1LQpdiKv65Rez77L9G3+/WpCMrSfK9+7PeVyUgF3flaBUqFPA3Rtjpx+uQQbE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:message-id:mime-version:content-type:content-transfer-encoding:x-mailer:thread-index:content-language:x-cr-hashedpuzzle:x-cr-puzzleid; b=qKJ8bhAa7FKquee8kW5VZGCaR9eAzt/8y+MOZSUz8a95lHc4tTJ/3HsczW6vpu2yDkFZmkvFH2k/IZokqF1BYPawv6rk33PdKxUI/2JDlvsW+VSqtymmJ86/63dkIqeHaSznxYPAmPER1CZGzAxMTkGfTkK9y3FkKK2NJwZoCP4= Received: by 10.100.202.9 with SMTP id z9mr6857300anf.42.1200058764383; Fri, 11 Jan 2008 05:39:24 -0800 (PST) Received: from 3sclient2 ( [61.48.169.1]) by mx.google.com with ESMTPS id 44sm3140770hsa.3.2008.01.11.05.39.21 (version=SSLv3 cipher=RC4-MD5); Fri, 11 Jan 2008 05:39:23 -0800 (PST) From: "SnaiX" To: Date: Fri, 11 Jan 2008 21:39:14 +0800 Message-ID: <00a001c85457$5e9e9c00$1bdbd400$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AchTUiaF5Z+BPFvTTSCpZr8rEuze+g== Content-Language: zh-cn x-cr-hashedpuzzle: D6g= YYI= A7pU BHu2 BawY DWSQ DkHN D9dR Ef1S FHGV FoRh Fq7O Gedy G4fk IpcW JpDh; 1; ZgByAGUAZQBiAHMAZAAtAG4AZQB0AEAAZgByAGUAZQBiAHMAZAAuAG8AcgBnAA==; Sosha1_v1; 7; {94674F88-0742-44AF-A7A6-AE00A107883C}; bgBhAHkAdQBoAHoAQABnAG0AYQBpAGwALgBjAG8AbQA=; Thu, 10 Jan 2008 06:29:27 GMT; dABoAGUAIABzAG8AYwBrAGUAdAAgAGMAYQBuACcAdAAgAGIAaQBuAGQAPwA= x-cr-puzzleid: {94674F88-0742-44AF-A7A6-AE00A107883C} Subject: the socket can't bind? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2008 14:06:32 -0000 Hi all, I attempt to run a program like this: 1. make a socket 2. set socket option with SO_REUSEADDR. 3. bind it 4. listen... accept...etc.. Alright, it works well. And I kill it, it can bind immediately. After this, I do: 5. close all fd. 6. reload it with execvp. So it would run 1-4. but it reports EADDRINUSE after bind. Why? How to resolve it? Should I dup() the fd? Thanks From owner-freebsd-net@FreeBSD.ORG Fri Jan 11 14:09:33 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F21316A4C5 for ; Fri, 11 Jan 2008 14:09:33 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: from hs-out-2122.google.com (hs-out-0708.google.com [64.233.178.242]) by mx1.freebsd.org (Postfix) with ESMTP id A5D8813C4D1 for ; Fri, 11 Jan 2008 14:09:32 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: by hs-out-2122.google.com with SMTP id h53so1204439hsh.11 for ; Fri, 11 Jan 2008 06:09:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=Ivqsw9gRG6eT6BA6zAAzhPFyYzJLbQ5jc03BXGtiU9E=; b=RoxIn4u/wLUA47gxXsQo8eiY4MwVNwu5AKsS6mwZSR+6zaCe7wDK6kxeiU3fnVeG5TM27QsBjFv8KZMwaikE6V8UF0RyFMXagwWxmCkGSMazQqGzyQ1huiVEVQV8dB0e2rL1EGfw4H21FDcJXMwAAKOWw5TwO+OpvPg1l4Tx2JU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=jyQPywgGnvRFo7sP5t3eRuLDW8LvxMx4w4cLhMRtWP308PeHXzCPoiIu1JOKg8dYEAtTq20Y7WE0Sy06/XKOfLLX8X/k9jSN1QVDlA2J4gF0+/at53N70lOPjil+mO6HLDTo5lzKipUlLHaBkcR/NDyIQWe5r7vz3/riaUvN1yY= Received: by 10.142.77.11 with SMTP id z11mr1626927wfa.98.1200060154571; Fri, 11 Jan 2008 06:02:34 -0800 (PST) Received: by 10.142.162.20 with HTTP; Fri, 11 Jan 2008 06:02:34 -0800 (PST) Message-ID: Date: Fri, 11 Jan 2008 22:02:34 +0800 From: "Sepherosa Ziehau" To: remko@freebsd.org In-Reply-To: <200801071728.m07HSsFl030966@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200801071728.m07HSsFl030966@freefall.freebsd.org> Cc: freebsd-net@freebsd.org, freebsd-bugs@freebsd.org Subject: Re: kern/119361: [bge] bge(4) transmit performance problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2008 14:09:33 -0000 On Jan 8, 2008 1:28 AM, wrote: > Synopsis: [bge] bge(4) transmit performance problem > > Responsible-Changed-From-To: freebsd-bugs->freebsd-net > Responsible-Changed-By: remko > Responsible-Changed-When: Mon Jan 7 17:28:37 UTC 2008 > Responsible-Changed-Why: > reassign to -net team > > http://www.freebsd.org/cgi/query-pr.cgi?pr=119361 Have you tested polling(4)? If polling could give you better TX performance, you should consider raise: in bge_attach() sc->bge_tx_max_coal_bds = 10; to 64 or more > _______________________________________________ > 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" > -- Live Free or Die From owner-freebsd-net@FreeBSD.ORG Fri Jan 11 14:21:03 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD4C016A417 for ; Fri, 11 Jan 2008 14:21:03 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.234]) by mx1.freebsd.org (Postfix) with ESMTP id 6CA0B13C43E for ; Fri, 11 Jan 2008 14:21:03 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: by nz-out-0506.google.com with SMTP id l8so612160nzf.13 for ; Fri, 11 Jan 2008 06:21:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=sM4qErg/R1nXhdTqhq5LFlh6ZWFpbDbIVhDgnYLoD0Y=; b=CjTDiomYbcZsBn0kYbTrlmnxRQCGcuFUItzkPgO3MW1k2cxjPxj2mk/fxtIp5sipMHehqO76JKFZ6N1AhhBNQz2d78SgX2m4mRkrYK8uJkCJioGrvmiWA7pfPWPL55NPe9wyOlzJfE5O/mGISUJTJRGKloBP26UQlN4Bv5FnZBw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=eG03gxqwstS9cEc2PTL0W+b9T5Hr6vFUA4jXmt5PNT+idLYJf6zLojaC7jNRu0ETJy8imf9X0fCPHdcER5xEPXzNvTtn9X+Y178n2aF2Nv4FH7vyDUoQMIRsckoo4yJ+7XsAyw7BWVVMXZwXMYJD7KjM79FpivnBChIs+PykEZE= Received: by 10.142.52.9 with SMTP id z9mr1616165wfz.237.1200059737680; Fri, 11 Jan 2008 05:55:37 -0800 (PST) Received: by 10.142.162.20 with HTTP; Fri, 11 Jan 2008 05:55:37 -0800 (PST) Message-ID: Date: Fri, 11 Jan 2008 21:55:37 +0800 From: "Sepherosa Ziehau" To: linimon@freebsd.org In-Reply-To: <200801110222.m0B2MuXT013420@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200801110222.m0B2MuXT013420@freefall.freebsd.org> Cc: freebsd-net@freebsd.org, freebsd-bugs@freebsd.org Subject: Re: kern/119548: [pf] [ath] PF Altq with ath hostap problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2008 14:21:03 -0000 On Jan 11, 2008 10:22 AM, wrote: > Old Synopsis: PF Altq with ath hostap problem > New Synopsis: [pf] [ath] PF Altq with ath hostap problem > > Responsible-Changed-From-To: freebsd-bugs->freebsd-net > Responsible-Changed-By: linimon > Responsible-Changed-When: Fri Jan 11 02:22:26 UTC 2008 > Responsible-Changed-Why: > Assign to -net mailing list. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=119548 Please test following patch: http://people.freebsd.org/~sephe/ieee80211_input.c.6_3.diff Best Regards, sephe -- Live Free or Die From owner-freebsd-net@FreeBSD.ORG Fri Jan 11 17:44:19 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D45BE16A41B; Fri, 11 Jan 2008 17:44:19 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A5BC113C468; Fri, 11 Jan 2008 17:44:19 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m0BHiJjj059341; Fri, 11 Jan 2008 17:44:19 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m0BHiJ6m059337; Fri, 11 Jan 2008 17:44:19 GMT (envelope-from linimon) Date: Fri, 11 Jan 2008 17:44:19 GMT Message-Id: <200801111744.m0BHiJ6m059337@freefall.freebsd.org> To: Mel@rachie.is-a-geek.net, linimon@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/119548: [pf] [ath] [patch] PF Altq with ath hostap problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2008 17:44:19 -0000 Old Synopsis: [pf] [ath] PF Altq with ath hostap problem New Synopsis: [pf] [ath] [patch] PF Altq with ath hostap problem State-Changed-From-To: open->feedback State-Changed-By: linimon State-Changed-When: Fri Jan 11 17:43:47 UTC 2008 State-Changed-Why: To submitter: a patch has been created, can you give it a try please? http://www.freebsd.org/cgi/query-pr.cgi?pr=119548 From owner-freebsd-net@FreeBSD.ORG Fri Jan 11 19:06:11 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4FB6016A41A; Fri, 11 Jan 2008 19:06:11 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id DEFF513C467; Fri, 11 Jan 2008 19:06:10 +0000 (UTC) (envelope-from sam@errno.com) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id m0BISGDE011437 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Jan 2008 10:28:18 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <4787B540.2040003@errno.com> Date: Fri, 11 Jan 2008 10:28:16 -0800 From: Sam Leffler User-Agent: Thunderbird 2.0.0.9 (X11/20071125) MIME-Version: 1.0 To: Sepherosa Ziehau References: <86ir2hznnd.fsf@ds4.des.no> <86abnpu0wv.fsf@ds4.des.no> <86abnovy4k.fsf@ds4.des.no> <86odc3dlgi.fsf@ds4.des.no> <86lk76c6t5.fsf@ds4.des.no> <864pds8idc.fsf@ds4.des.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-DCC--Metrics: ebb.errno.com; whitelist Cc: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , kevlo@freebsd.org, current@freebsd.org, net@freebsd.org Subject: Re: if_ral regression [was seq#'s on ap frames] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2008 19:06:11 -0000 Sepherosa Ziehau wrote: > On Jan 5, 2008 10:19 PM, Dag-Erling Smørgrav wrote: > >> "Sepherosa Ziehau" writes: >> >>> This actually brings up two things: >>> 1) I think we should ignore seq in multicast frames; this is permitted in >>> 802.11 standard. In dfly I did that, since one of our users >>> encountered a broken commercial AP which is not 802.11e but uses >>> different seq for data and beacon. >>> 2) TX sequence. I think standards only mention QSTA/nQSTA, but not >>> AP. Currently our AP uses per node TX seq, which means beacon's seq >>> is difficult to choose, at least for 2560 based ral(4), whose beacons' >>> seq need to be set by software. I saw Linksys AP uses one seq for all >>> of the frames it sends. Sam, what's you opinion on this? >>> >>> I think if STA counts ral(4)'s beacon seq, as what we do currently, >>> beacon missing will quickly happen since beacons will be discarded >>> after first several data frames. >>> >> OK, I *think* I understood most of that. Does this suggest a solution >> to you? I will try to get the wlandebug output tonight. >> > > I don't know whether you are still interested to track down the wired > problem you had experienced. > If you have time please try following patches: > > revert the old patch at your AP side and try this one > http://people.freebsd.org/~sephe/rt2560_test.diff1 > > apply following patch at you STA side > http://people.freebsd.org/~sephe/ieee80211_input.c.diff > > Best Regards, > sephe > > [just back from holiday and only now caught your question about seq#'s] The issue of seq# generation has mostly been ignored because many/most devices generate them directly. I'm aware of issues w/ management frames not getting correct seq#'s for ap mode (e.g. probe response) and have some uncommitted changes. Beacon frames should track the seq# in the bss node though there might be some trickiness w/ the bss node being rebuilt too much (we may need to propagate the current seq# as we do some other state). On the rx side I'm not sure about ignoring seq# of mcast frames; it would definitely be a WAR for broken ap implementations. FWIW I took ownership of a ral bug where AP mode tx just stopped for no apparent reason (I think it was probe response frames but can't recall). This sounds like the same thing; can you check kern/117655? Sam From owner-freebsd-net@FreeBSD.ORG Fri Jan 11 19:15:07 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9C9B16A418 for ; Fri, 11 Jan 2008 19:15:07 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by mx1.freebsd.org (Postfix) with ESMTP id 8CAA813C457 for ; Fri, 11 Jan 2008 19:15:07 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id D6F4F88D24; Fri, 11 Jan 2008 14:15:06 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Fri, 11 Jan 2008 14:15:06 -0500 X-Sasl-enc: 2zsHZHZogOWnZ8fAZ/MkzEgtd8g7/sq42malng4sP855 1200078906 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 62E80D18E; Fri, 11 Jan 2008 14:15:06 -0500 (EST) Message-ID: <4787C039.6080205@FreeBSD.org> Date: Fri, 11 Jan 2008 19:15:05 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.6 (X11/20070928) MIME-Version: 1.0 To: SnaiX References: <00a001c85457$5e9e9c00$1bdbd400$@com> In-Reply-To: <00a001c85457$5e9e9c00$1bdbd400$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: the socket can't bind? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2008 19:15:07 -0000 SnaiX wrote: > So it would run 1-4. but it reports EADDRINUSE after bind. > > Why? The stack assumes that SO_REUSEADDR is never cleared on a socket after it gets set. > How to resolve it? Should I dup() the fd? > Did you close the affected socket in (5) ? Presumably you are still trying to use the same port; is it a non-ephemeral port? You might want to consider SO_REUSEPORT although I believe FreeBSD doesn't fully support it for non-multicast. BMS From owner-freebsd-net@FreeBSD.ORG Fri Jan 11 23:20:04 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A47516A47F for ; Fri, 11 Jan 2008 23:20:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id EFFB313C447 for ; Fri, 11 Jan 2008 23:20:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m0BNK3P9088293 for ; Fri, 11 Jan 2008 23:20:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m0BNK3eJ088292; Fri, 11 Jan 2008 23:20:03 GMT (envelope-from gnats) Date: Fri, 11 Jan 2008 23:20:03 GMT Message-Id: <200801112320.m0BNK3eJ088292@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Harrison Grundy Cc: Subject: Re: kern/119225: 7.0-RC1 no carrier with Prism 2.5 wifi card X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Harrison Grundy List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2008 23:20:04 -0000 The following reply was made to PR kern/119225; it has been noted by GNATS. From: Harrison Grundy To: bug-followup@FreeBSD.org, jyrki.k@post.cz Cc: Subject: Re: kern/119225: 7.0-RC1 no carrier with Prism 2.5 wifi card Date: Sat, 12 Jan 2008 07:48:32 +0900 I have seen the same behavior on a Prism 2.5 system I've got. The NDISulator driver works fine, though. From owner-freebsd-net@FreeBSD.ORG Sat Jan 12 07:00:06 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 311E416A417 for ; Sat, 12 Jan 2008 07:00:06 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 2A81013C442 for ; Sat, 12 Jan 2008 07:00:06 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m0C7057t007261 for ; Sat, 12 Jan 2008 07:00:05 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m0C705JI007260; Sat, 12 Jan 2008 07:00:05 GMT (envelope-from gnats) Date: Sat, 12 Jan 2008 07:00:05 GMT Message-Id: <200801120700.m0C705JI007260@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: KUROSAWA Takahiro Cc: Subject: Re: kern/116837: ifconfig tunX destroy: panic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: KUROSAWA Takahiro List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jan 2008 07:00:06 -0000 The following reply was made to PR kern/116837; it has been noted by GNATS. From: KUROSAWA Takahiro To: bug-followup@FreeBSD.org, jkpyvxmzsa@mailinator.com Cc: Subject: Re: kern/116837: ifconfig tunX destroy: panic Date: Sat, 12 Jan 2008 15:48:39 +0900 The KASSERT() check in tun_destroy() seems incorrect since the function can actually be called while a user thread is opening /dev/tunX. If we needed to ensure that no threads have fd for /dev/tunX in tun_destroy(), we should implement it in if_tun. Instead, we can rely on destroy_dev() to ensure that no threads access /dev/tunX anymore (the function blocks when there are threads accessing the device). But just deleting KASSERT() is insufficient because there is a race condition: tun_destroy() calls if_free() before destroy_dev(), so user threads might access the destroyed ifnet structure by read()/write()/... on /dev/tunX. I guess the following change is needed for if_tun.c: --- sys/net/if_tun.c 2008/01/11 04:14:11 1.1 +++ sys/net/if_tun.c 2008/01/12 04:04:39 @@ -249,15 +249,12 @@ tun_destroy(struct tun_softc *tp) { struct cdev *dev; - /* Unlocked read. */ - KASSERT((tp->tun_flags & TUN_OPEN) == 0, - ("tununits is out of sync - unit %d", TUN2IFP(tp)->if_dunit)); - dev = tp->tun_dev; + /* destroy_dev() ensures no threads access /dev/tunX anymore. */ + destroy_dev(dev); bpfdetach(TUN2IFP(tp)); if_detach(TUN2IFP(tp)); if_free(TUN2IFP(tp)); - destroy_dev(dev); knlist_destroy(&tp->tun_rsel.si_note); mtx_destroy(&tp->tun_mtx); free(tp, M_TUN); From owner-freebsd-net@FreeBSD.ORG Sat Jan 12 10:02:53 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0EBEB16A41B; Sat, 12 Jan 2008 10:02:53 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 788DF13C4DD; Sat, 12 Jan 2008 10:02:52 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id E3D4320B9; Sat, 12 Jan 2008 11:02:42 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.2/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id C327120B1; Sat, 12 Jan 2008 11:02:42 +0100 (CET) Received: by ds4.des.no (Postfix, from userid 1001) id B013D8449F; Sat, 12 Jan 2008 11:02:42 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Sam Leffler References: <86ir2hznnd.fsf@ds4.des.no> <86abnpu0wv.fsf@ds4.des.no> <86abnovy4k.fsf@ds4.des.no> <86odc3dlgi.fsf@ds4.des.no> <86lk76c6t5.fsf@ds4.des.no> <864pds8idc.fsf@ds4.des.no> <4787B540.2040003@errno.com> Date: Sat, 12 Jan 2008 11:02:42 +0100 In-Reply-To: <4787B540.2040003@errno.com> (Sam Leffler's message of "Fri\, 11 Jan 2008 10\:28\:16 -0800") Message-ID: <867iif7459.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Sepherosa Ziehau , kevlo@freebsd.org, current@freebsd.org, net@freebsd.org Subject: Re: if_ral regression X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jan 2008 10:02:53 -0000 Sam Leffler writes: > FWIW I took ownership of a ral bug where AP mode tx just stopped for > no apparent reason (I think it was probe response frames but can't > recall). This sounds like the same thing; can you check kern/117655? Looks similar, except for the part about the PCI version - my AP is a soekris net4801 which I suspect supports only good old 1.1. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-net@FreeBSD.ORG Sat Jan 12 11:23:38 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 10F4816A419 for ; Sat, 12 Jan 2008 11:23:38 +0000 (UTC) (envelope-from fli@shapeshifter.se) Received: from mx1.h3q.net (mx1.h3q.net [212.37.5.30]) by mx1.freebsd.org (Postfix) with ESMTP id 9213F13C447 for ; Sat, 12 Jan 2008 11:23:37 +0000 (UTC) (envelope-from fli@shapeshifter.se) Received: from [192.168.1.100] (78-69-107-234-no83.tbcn.telia.com [78.69.107.234]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: fli@shapeshifter.se) by mx1.h3q.net (Postfix) with ESMTP id 066F078C20 for ; Sat, 12 Jan 2008 12:07:03 +0100 (CET) Message-ID: <47889F53.4010605@shapeshifter.se> Date: Sat, 12 Jan 2008 12:06:59 +0100 From: Fredrik Lindberg User-Agent: Thunderbird 2.0.0.9 (X11/20071129) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: multipart/mixed; boundary="------------010609050507030507010803" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Unexpected multicast IPv4 socket behavior X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jan 2008 11:23:38 -0000 This is a multi-part message in MIME format. --------------010609050507030507010803 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi I find the following socket behavior a bit unexpected. Multicast from an IPv4 socket (with IP_MULTICAST_IF set) with its source address bound to INADDR_ANY only works if there is a default route defined, otherwise send() returns ENETUNREACH. Default route set, src INADDR_ANY : Works Default route set, src bind() to interface address : Works No default route, src INADDR_ANY : Returns ENETUNREACH No default route, src bind() to interface address : Works In all cases IP_MULTICAST_IF was set to the outgoing interface and IP_ADD_MEMBERSHIP was properly called. IGMP membership reports were seen on the link in all cases. I believe the cause of this (unless this is the expected behavior?) is in in_pcbconnect_setup() (netinet/in_pcb.c) [1]. The check for a multicast destination address is run after the attempt to get the source address by finding a directly connected interface, this check also returns ENETUNREACH if it fails (which it does for the destination 224.0.0.0/24 if no default route is set). Moving the multicast check before the directly connected check solves this (or any other combinations that makes sure that the IN_MULTICAST() check is executed). I've attached a test case and a patch to illustrate it, comments? Fredrik Lindberg [1] http://fxr.watson.org/fxr/source/netinet/in_pcb.c#L610 --------------010609050507030507010803 Content-Type: text/x-patch; name="in_pcb.c-multicast.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="in_pcb.c-multicast.patch" Index: netinet/in_pcb.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/in_pcb.c,v retrieving revision 1.198 diff -d -u -r1.198 in_pcb.c --- netinet/in_pcb.c 22 Dec 2007 10:06:11 -0000 1.198 +++ netinet/in_pcb.c 12 Jan 2008 10:48:08 -0000 @@ -618,26 +618,6 @@ if ((inp->inp_socket->so_options & SO_DONTROUTE) == 0) ia = ip_rtaddr(faddr); /* - * If we found a route, use the address corresponding to - * the outgoing interface. - * - * Otherwise assume faddr is reachable on a directly connected - * network and try to find a corresponding interface to take - * the source address from. - */ - if (ia == 0) { - bzero(&sa, sizeof(sa)); - sa.sin_addr = faddr; - sa.sin_len = sizeof(sa); - sa.sin_family = AF_INET; - - ia = ifatoia(ifa_ifwithdstaddr(sintosa(&sa))); - if (ia == 0) - ia = ifatoia(ifa_ifwithnet(sintosa(&sa))); - if (ia == 0) - return (ENETUNREACH); - } - /* * If the destination address is multicast and an outgoing * interface has been set as a multicast option, use the * address of that interface as our source address. @@ -657,6 +637,26 @@ return (EADDRNOTAVAIL); } } + /* + * If we found a route, use the address corresponding to + * the outgoing interface. + * + * Otherwise assume faddr is reachable on a directly connected + * network and try to find a corresponding interface to take + * the source address from. + */ + if (ia == 0) { + bzero(&sa, sizeof(sa)); + sa.sin_addr = faddr; + sa.sin_len = sizeof(sa); + sa.sin_family = AF_INET; + + ia = ifatoia(ifa_ifwithdstaddr(sintosa(&sa))); + if (ia == 0) + ia = ifatoia(ifa_ifwithnet(sintosa(&sa))); + if (ia == 0) + return (ENETUNREACH); + } laddr = ia->ia_addr.sin_addr; } --------------010609050507030507010803-- From owner-freebsd-net@FreeBSD.ORG Sat Jan 12 12:56:45 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D22C216A417 for ; Sat, 12 Jan 2008 12:56:45 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by mx1.freebsd.org (Postfix) with ESMTP id 9CA3513C474 for ; Sat, 12 Jan 2008 12:56:45 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 5CB4F8833B; Sat, 12 Jan 2008 07:56:45 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Sat, 12 Jan 2008 07:56:45 -0500 X-Sasl-enc: +A7PDZCMpv+ufXe2Rr9za2OJNqA0/DuYl4GtZ+bskZP8 1200142604 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 8399A2BAAE; Sat, 12 Jan 2008 07:56:44 -0500 (EST) Message-ID: <4788B90A.2080901@FreeBSD.org> Date: Sat, 12 Jan 2008 12:56:42 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.6 (X11/20070928) MIME-Version: 1.0 To: Fredrik Lindberg References: <47889F53.4010605@shapeshifter.se> In-Reply-To: <47889F53.4010605@shapeshifter.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Unexpected multicast IPv4 socket behavior X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jan 2008 12:56:46 -0000 Hi, This is ironic because I've been up against a similar problem with 255.255.255.255 on my current project, which also requires a 'bump in the stack', and the same code you've posted the patch for, I found myself reading yesterday to answer another chap's query. Fredrik Lindberg wrote: > Hi > > I find the following socket behavior a bit unexpected. Multicast from > an IPv4 socket (with IP_MULTICAST_IF set) with its source address bound > to INADDR_ANY only works if there is a default route defined, otherwise > send() returns ENETUNREACH. > > Default route set, src INADDR_ANY : Works > Default route set, src bind() to interface address : Works > No default route, src INADDR_ANY : Returns ENETUNREACH > No default route, src bind() to interface address : Works Totally expected behaviour. There's no way for the stack to know which interface to originate the traffic from in the case where there is no default route, and no IP layer source information elsewhere in the stack. It could be argued that case 3 is in fact an abuse of the APIs. In IPv6, the use of multicast requires that you create a socket and bind to the interface where you wish to send and receive the channel. This is reasonable because both IGMP and MLD require that their group state traffic is bound to a specific address. Thus the glaring holes in IGMP due to the lack of IPv4 link-local addressing. The newer multicast APIs in fact require you to do this, precisely to avoid this ambiguity. As such IP_MULTICAST_IF should be considered legacy -- however -- as we've seen, there's a lack of knowledge out there about exactly how this stuff is supposed to work. > > In all cases IP_MULTICAST_IF was set to the outgoing interface and > IP_ADD_MEMBERSHIP was properly called. IGMP membership reports > were seen on the link in all cases. Now, if you are explicitly telling the stack which interface to use with IP_MULTICAST_IF, and you are seeing the regression in case 3 above, THAT looks like a bug. > > I believe the cause of this (unless this is the expected behavior?) > is in in_pcbconnect_setup() (netinet/in_pcb.c) [1]. > The check for a multicast destination address is run after the attempt > to get the source address by finding a directly connected interface, > this check also returns ENETUNREACH if it fails (which it does for the > destination 224.0.0.0/24 if no default route is set). But but but. Sends to 224.0.0.0/*24* should never fail as it is strictly scoped to a link, and does not require any IPv4 route information. This is the lonesome kicker -- IP needs to know where to source the send from, however, you've told it to already with IP_MULTICAST_IF, so there is definitely a bug. See the IN_LOCAL_GROUP() macro in -CURRENT's netinet/in.h for how to check for 224.0.0.0/24 in code. In fact we should probably disallow multicast sends to this address when the socket HAS NOT been bound, except of course for the case where the interface is unnumbered -- but we still need a means of telling the stack about this case. The answer might be something called IP_SENDIF... Linux uses SO_BINDTODEVICE for this. It's a case of sitting down and doing it. It's reasonable to assume that multicast applications should know that they need to walk the system's interface tree and be aware of interfaces and their addresses. Apps which don't do this are legacy and need to be updated to reflect how IP stacks actually behave now. > > Moving the multicast check before the directly connected check solves > this (or any other combinations that makes sure that the > IN_MULTICAST() check is executed). You are quite right that the imo_multicast_ifp check needs to happen further up. This is probably OK as a workaround -- but -- bigger changes need to happen in that code as currently source selection is mostly based on destination. This isn't always the case, and in multicast it certainly ISN'T the case as you have seen. SO_DONTROUTE is something of a misnomer anyway. Routes still need to be present in the forwarding table for certain lookups, and the source interface selection is almost wholly based on the destination faddr in the inpcb, in both the cases of connect() and temporary connect during a sendto(). Your patch should be OK to go in. Regardless of whether there are routes for the multicast channel you're using or not, IP_MULTICAST_IF is a sledgehammer which says 'I use THIS interface for multicast', and until our IPv4 stack has link scope addresses, it will be needed. Thanks again... BMS From owner-freebsd-net@FreeBSD.ORG Sat Jan 12 15:33:03 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D72616A420 for ; Sat, 12 Jan 2008 15:33:03 +0000 (UTC) (envelope-from fli@shapeshifter.se) Received: from mx1.h3q.net (mx1.h3q.net [212.37.5.30]) by mx1.freebsd.org (Postfix) with ESMTP id D38A913C442 for ; Sat, 12 Jan 2008 15:33:02 +0000 (UTC) (envelope-from fli@shapeshifter.se) Received: from [192.168.1.100] (78-69-107-234-no83.tbcn.telia.com [78.69.107.234]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: fli@shapeshifter.se) by mx1.h3q.net (Postfix) with ESMTP id C3A8178C20; Sat, 12 Jan 2008 16:33:00 +0100 (CET) Message-ID: <4788DDAB.7080408@shapeshifter.se> Date: Sat, 12 Jan 2008 16:32:59 +0100 From: Fredrik Lindberg User-Agent: Thunderbird 2.0.0.9 (X11/20071129) MIME-Version: 1.0 To: "Bruce M. Simpson" References: <47889F53.4010605@shapeshifter.se> <4788B90A.2080901@FreeBSD.org> In-Reply-To: <4788B90A.2080901@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Unexpected multicast IPv4 socket behavior X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jan 2008 15:33:03 -0000 Bruce M. Simpson wrote: >> >> I find the following socket behavior a bit unexpected. Multicast from >> an IPv4 socket (with IP_MULTICAST_IF set) with its source address bound >> to INADDR_ANY only works if there is a default route defined, otherwise >> send() returns ENETUNREACH. >> >> Default route set, src INADDR_ANY : Works >> Default route set, src bind() to interface address : Works >> No default route, src INADDR_ANY : Returns ENETUNREACH >> No default route, src bind() to interface address : Works > > Totally expected behaviour. There's no way for the stack to know which > interface to originate the traffic from in the case where there is no > default route, and no IP layer source information elsewhere in the stack. > I would expect this _without_ IP_MULTICAST_IF set, however as I said the interface had been explicitly set with IP_MULTICAST_IF in all 4 cases, so there indeed is enough information in the stack to send the packet. It seems that my test case got stripped of the mail, this was supposed to be attached to the original post. So just for the record http://manticore.h3q.net/~fli/multicast.c > It could be argued that case 3 is in fact an abuse of the APIs. In IPv6, > the use of multicast requires that you create a socket and bind to the > interface where you wish to send and receive the channel. This is > reasonable because both IGMP and MLD require that their group state > traffic is bound to a specific address. Thus the glaring holes in IGMP > due to the lack of IPv4 link-local addressing. > > The newer multicast APIs in fact require you to do this, precisely to > avoid this ambiguity. As such IP_MULTICAST_IF should be considered > legacy -- however -- as we've seen, there's a lack of knowledge out > there about exactly how this stuff is supposed to work. > If IP_MULTICAST_IF should be considered legacy, I'll move away from it. But, as you said, there is probably a lack of knowledge on how the APIs should be used and I have never seen anyone or any document (maybe I haven't looked hard enough) that suggests that this usage is deprecated. >> >> In all cases IP_MULTICAST_IF was set to the outgoing interface and >> IP_ADD_MEMBERSHIP was properly called. IGMP membership reports >> were seen on the link in all cases. > > Now, if you are explicitly telling the stack which interface to use with > IP_MULTICAST_IF, and you are seeing the regression in case 3 above, THAT > looks like a bug. > Yes, that was the whole point. >> >> I believe the cause of this (unless this is the expected behavior?) >> is in in_pcbconnect_setup() (netinet/in_pcb.c) [1]. >> The check for a multicast destination address is run after the attempt >> to get the source address by finding a directly connected interface, >> this check also returns ENETUNREACH if it fails (which it does for the >> destination 224.0.0.0/24 if no default route is set). > > But but but. Sends to 224.0.0.0/*24* should never fail as it is strictly > scoped to a link, and does not require any IPv4 route information. This > is the lonesome kicker -- IP needs to know where to source the send > from, however, you've told it to already with IP_MULTICAST_IF, so there > is definitely a bug. I know that 224.0.0.0/24 is link-local, I just happened to use that as a test case. But I wouldn't expect anything in 224.0.0.0/4 to fail _with_ IP_MULTICAST_IF set. > > See the IN_LOCAL_GROUP() macro in -CURRENT's netinet/in.h for how to > check for 224.0.0.0/24 in code. > > In fact we should probably disallow multicast sends to this address when > the socket HAS NOT been bound, except of course for the case where the > interface is unnumbered -- but we still need a means of telling the > stack about this case. The answer might be something called IP_SENDIF... > Linux uses SO_BINDTODEVICE for this. It's a case of sitting down and > doing it. For the purpose of avoiding sends to 224.0.0.0/24 to go via the default route? IP_SENDIF/SO_BINDTODEVICE seems to show up from time to time, is the only reason that it hasn't been implemented simply that nobody has done it? Fredrik From owner-freebsd-net@FreeBSD.ORG Sat Jan 12 20:10:59 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3128416A41A for ; Sat, 12 Jan 2008 20:10:59 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by mx1.freebsd.org (Postfix) with ESMTP id E51A713C478 for ; Sat, 12 Jan 2008 20:10:58 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id AEF7587617; Sat, 12 Jan 2008 15:10:58 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Sat, 12 Jan 2008 15:10:58 -0500 X-Sasl-enc: ptZIH/64VejXG+gTzBY6o3Pwjf4mRrKZEM3Bf+07Gkgq 1200168658 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 2EDCD6310; Sat, 12 Jan 2008 15:10:58 -0500 (EST) Message-ID: <47891ED1.6070506@FreeBSD.org> Date: Sat, 12 Jan 2008 20:10:57 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.6 (X11/20070928) MIME-Version: 1.0 To: Fredrik Lindberg References: <47889F53.4010605@shapeshifter.se> <4788B90A.2080901@FreeBSD.org> <4788DDAB.7080408@shapeshifter.se> In-Reply-To: <4788DDAB.7080408@shapeshifter.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Unexpected multicast IPv4 socket behavior X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jan 2008 20:10:59 -0000 Fredrik Lindberg wrote: > > I would expect this _without_ IP_MULTICAST_IF set, however as I said > the interface had been explicitly set with IP_MULTICAST_IF in all 4 > cases, so there indeed is enough information in the stack to send > the packet. Correct. You found a bug. Well done. > > If IP_MULTICAST_IF should be considered legacy, I'll move away from it. > But, as you said, there is probably a lack of knowledge on how the > APIs should be used and I have never seen anyone or any document > (maybe I haven't looked hard enough) that suggests that this usage is > deprecated. The fact that IPv4 multicast sends appear to work using the default route is a historical quirk. It is not multicast forwarding. For a host/endstation, the mere fact that the group was joined on a given socket, on a given interface, should be enough IP layer reachability information for the inpcb layer to figure out where to send the packets. From that point on, it's the problem of the multicast routers on the path between the end-station and the other members of the channel, which are normally speaking PIM-SM. If one follows how IGMP works, then the problem with multicast joins which are not scoped to an interface is readily obvious. IGMP/MLD is necessary to inform upstream routers that the channel is being opened -- otherwise, you will not receive traffic for the group, as the state about the end-station's participation in the channel is never communicated to routers. The endpoint address used by the local end of the path in MLD is the link-scope IPv6 address. In IGMP, it's the first IPv4 address configured on the interface. Both IGMP and MLD are always scoped to the local link -- they deal with multicast forwarding and membership state ONLY in the domain of the link they are used on. IPv4 has historically not had link-scope addresses, which are one possible answer to the problem. Ergo there is a problem if the interface is unnumbered -- or if the inpcb laddr is 0.0.0.0 -- which you have seen. It should be possible to use IP_MULTICAST_IF as a workaround for this, however, you found that path is buggy... I guess the textbooks out there haven't caught up with reality. > > I wouldn't expect anything in 224.0.0.0/4 to fail > _with_ IP_MULTICAST_IF set. Correct. This makes the bug even more damaging. It is reasonable for a system to be using multicast during early boot when all interfaces are unnumbered. In fact the IGMPv3 RFC suggests no IGMP traffic should be sent for groups in 224.0.0.0/24, becuase upstream IGMP routers should never be forwarding these groups between links. Unfortunately, in practice, this can break layer 2 multicasts for these groups which traverse IGMP snooping switches. > > IP_SENDIF/SO_BINDTODEVICE seems to show up from time to time, is > the only reason that it hasn't been implemented simply that nobody > has done it? Yup. Everyone seems to be too worried about unicast traffic and bulk I/O performance to bother much with other applications of IP, so, this sort of issue gets more airtime elsewhere. later BMS From owner-freebsd-net@FreeBSD.ORG Sat Jan 12 23:30:31 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9738E16A419 for ; Sat, 12 Jan 2008 23:30:31 +0000 (UTC) (envelope-from ericx@vineyard.net) Received: from vineyard.net (k1.vineyard.net [204.17.195.90]) by mx1.freebsd.org (Postfix) with ESMTP id 551D213C458 for ; Sat, 12 Jan 2008 23:30:31 +0000 (UTC) (envelope-from ericx@vineyard.net) Received: from localhost (loopback [127.0.0.1]) by vineyard.net (Postfix) with ESMTP id 545B591508 for ; Sat, 12 Jan 2008 18:13:23 -0500 (EST) X-Virus-Scanned: by AMaViS-king1 at Vineyard.NET Received: from vineyard.net ([127.0.0.1]) by localhost (king1.vineyard.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id nn4Wj9ZUwNXs for ; Sat, 12 Jan 2008 18:13:23 -0500 (EST) Received: from cheesenip.vineyard.net (cheesenip.vineyard.net [204.17.195.113]) by vineyard.net (Postfix) with ESMTP id 1416A91504 for ; Sat, 12 Jan 2008 18:13:23 -0500 (EST) Message-ID: <47894992.8080202@vineyard.net> Date: Sat, 12 Jan 2008 18:13:22 -0500 From: "Eric W. Bates" Organization: Vineyard.NET, Inc. User-Agent: Thunderbird 2.0.0.9 (X11/20080102) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: bgp router preferences X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jan 2008 23:30:31 -0000 I think I have finally given up on cisco. What are folks recommendations for a machine doing full bgp routes? I think I need to get a Sangoma card; but what is the current favorite bgp routing software and how much RAM do folks think I can get away with? Thanks for your time. -- Eric W. Bates ericx@vineyard.net