From owner-freebsd-net@FreeBSD.ORG Sun Aug 20 04:57:05 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BB04B16A4DA; Sun, 20 Aug 2006 04:57:05 +0000 (UTC) (envelope-from prvs=julian=38058dedd@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7752E43D49; Sun, 20 Aug 2006 04:57:05 +0000 (GMT) (envelope-from prvs=julian=38058dedd@elischer.org) Received: from unknown (HELO [192.168.2.3]) ([10.251.60.51]) by a50.ironport.com with ESMTP; 19 Aug 2006 21:57:04 -0700 Message-ID: <44E7EB9F.5060503@elischer.org> Date: Sat, 19 Aug 2006 21:57:03 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ruslan Ermilov References: <64de5c8b0608190514l1c2241edj57b114997e01a8b2@mail.gmail.com> <20060819125550.GA8879@rambler-co.ru> <64de5c8b0608190635q1fe2c0c5oe5d258748c1c5c95@mail.gmail.com> <20060819135133.GC9271@rambler-co.ru> <64de5c8b0608190728k47c9dd50kfaf8b94096aa128e@mail.gmail.com> <20060819154215.GB9883@rambler-co.ru> In-Reply-To: <20060819154215.GB9883@rambler-co.ru> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Rajkumar S Subject: Re: ng_ip_input ? 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, 20 Aug 2006 04:57:05 -0000 Ruslan Ermilov wrote: >On Sat, Aug 19, 2006 at 07:58:03PM +0530, Rajkumar S wrote: > > >>On 8/19/06, Ruslan Ermilov wrote: >> >> >>>On Sat, Aug 19, 2006 at 07:05:49PM +0530, Rajkumar S wrote: >>> >>> >>>>Any points to docs to read about a packet's traversal in FreeBSD ip >>>>stack? (especially wrt pf) >>>> >>>> >>>> >>>What level of detalization do you need? Filters, such as pf(4), are >>>embedded into the normal processing using the pfil(9) API. >>> >>> >>I am a relative newbie learning freebsd. A broad overview with >>pointers to manpages are ideal. like the the simple pointer to >>pfil(9) you gave along with a small description of where it appears. >> >> >> >Then you can always start from reading the source code. >It's been written by human beings. :-) > > while the above seems harsh it turns out that /sys/netinet/ip_input.c is in fact a very easy file to read due to the serial nature of ip processing.. give it a try > >Cheers, > > From owner-freebsd-net@FreeBSD.ORG Mon Aug 21 05:36:15 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 11FA216A4DA for ; Mon, 21 Aug 2006 05:36:15 +0000 (UTC) (envelope-from rajkumars@gmail.com) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE74943D5A for ; Mon, 21 Aug 2006 05:36:13 +0000 (GMT) (envelope-from rajkumars@gmail.com) Received: by nz-out-0102.google.com with SMTP id x3so687009nzd for ; Sun, 20 Aug 2006 22:36:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=QiZF4+IGMoCFPksJjtCbteUQ8mWYcdC7iSlf3jZ4yTUSsiJYiKQ/rawn/xR6AxjKeBNcI7PGbZ1gs67rDbrvCWn+O0J4PxGXVUJvEdWjpphxT75z34rFiz2yG528Z8dLmS7g1M++2RXQ5G0q79dOR0KNqasUCEUFuSRPBQ802Io= Received: by 10.65.81.19 with SMTP id i19mr6230119qbl; Sun, 20 Aug 2006 22:36:13 -0700 (PDT) Received: by 10.65.248.1 with HTTP; Sun, 20 Aug 2006 22:36:13 -0700 (PDT) Message-ID: <64de5c8b0608202236pd710ff4rbd67764c6096c06@mail.gmail.com> Date: Mon, 21 Aug 2006 11:06:13 +0530 From: "Rajkumar S" To: freebsd-net@freebsd.org In-Reply-To: <44E7EB9F.5060503@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <64de5c8b0608190514l1c2241edj57b114997e01a8b2@mail.gmail.com> <20060819125550.GA8879@rambler-co.ru> <64de5c8b0608190635q1fe2c0c5oe5d258748c1c5c95@mail.gmail.com> <20060819135133.GC9271@rambler-co.ru> <64de5c8b0608190728k47c9dd50kfaf8b94096aa128e@mail.gmail.com> <20060819154215.GB9883@rambler-co.ru> <44E7EB9F.5060503@elischer.org> Subject: Re: ng_ip_input ? 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, 21 Aug 2006 05:36:15 -0000 On 8/20/06, Julian Elischer wrote: > while the above seems harsh it turns out that /sys/netinet/ip_input.c is > in fact a very easy file to > read due to the serial nature of ip processing.. give it a try Sure, Thanks a lot, I am just getting my feet wet in freebsd! raj From owner-freebsd-net@FreeBSD.ORG Mon Aug 21 09:09:51 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4BE1C16A4E0 for ; Mon, 21 Aug 2006 09:09:51 +0000 (UTC) (envelope-from mendonan@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.191]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8BE9A43D45 for ; Mon, 21 Aug 2006 09:09:50 +0000 (GMT) (envelope-from mendonan@gmail.com) Received: by nf-out-0910.google.com with SMTP id n29so2032570nfc for ; Mon, 21 Aug 2006 02:09:49 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=VX7iG3g3wD+VYh0Nm4olxlEbbFBZKSASNE2/movqixbl6XWWuf1EkWbBPDmFSXN9g3T0y7xcVvMTVdZaJPLbXEgmpIvsIqcBQ+mK63FFmXsD8PpwRx5RHagSUen5Upa9ZTjnyBuQvBpwF9EJ+pf0Y7Vi5INHpRSnlGjFXXDGx0c= Received: by 10.49.8.15 with SMTP id l15mr7493378nfi; Mon, 21 Aug 2006 02:09:49 -0700 (PDT) Received: by 10.78.173.7 with HTTP; Mon, 21 Aug 2006 02:09:49 -0700 (PDT) Message-ID: <94c7120b0608210209o482fef7ev1b4922d0597af666@mail.gmail.com> Date: Mon, 21 Aug 2006 17:09:49 +0800 From: "Senandung Mendonan" To: freebsd-net@freebsd.org In-Reply-To: <09BFF2FA5EAB4A45B6655E151BBDD90301D42713@NT-IRVA-0750.brcm.ad.broadcom.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <94c7120b0608181236j2475301ds1379510f94b12d34@mail.gmail.com> <09BFF2FA5EAB4A45B6655E151BBDD90301D42713@NT-IRVA-0750.brcm.ad.broadcom.com> Subject: Re: Problem with IBM NetXtreme 1000-T GigaEthernet Adapter 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, 21 Aug 2006 09:09:51 -0000 David, On 8/19/06, David Christensen wrote: > > > I tried to use a FE version of the switch (Cisco Catalyst > > C3750), and a > > single-port version of the said NIC, with the same results > > (auto detect > > fails, and can only live with intermittent forced 100baseTX > > full-duplex). > > There isn't a single port version of the 5704, it must be a different > controller (maybe the 5703?). Which one is it exactly? You are right: the single-port version is actually the 5703. Here's the dmesg output for this particular one:- pci5: on pcib4 bge0: mem 0xdcff0000-0xdc ffffff irq 48 at device 1.0 on pci5 miibus0: on bge0 brgphy0: on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX -FDX, auto bge0: Ethernet address: 00:10:18:16:43:d6 > Do either the > LOM devices or the add-in boards support remote management (such as > Serial-over-LAN or IPMI)? If so does disabling the feature change the > problem? No idea on this one. Where do I usually disable this -- in the BIOS I presume? > If you could attach a dump of dmesg that shows the messages from the > driver that might help too. Here's the dmesg for the dual-port version:- pci5: on pcib4 bge0: mem 0xdcff0000-0xdcffffff irq 48 at device 1.0 on pci5 miibus0: on bge0 brgphy0: on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto bge0: Ethernet address: 00:10:18:11:2a:0d bge1: mem 0xdcfe0000-0xdcfeffff irq 49 at device 1.1 on pci5 miibus1: on bge1 brgphy1: on miibus1 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto bge1: Ethernet address: 00:10:18:11:2a:0a Thanks. > > > --mendonan > > "Yang mimpikan secangkir kopi panas dengan selimut.." > > (Dreaming of a cup of hot coffee, and a blanket..") > > _______________________________________________ > > 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" > > > > > > -- --mendonan "Yang mimpikan secangkir kopi panas dengan selimut.." (Dreaming of a cup of hot coffee, and a blanket..") From owner-freebsd-net@FreeBSD.ORG Mon Aug 21 09:23:53 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B677116A4DF; Mon, 21 Aug 2006 09:23:53 +0000 (UTC) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (insomnia.benzedrine.cx [62.65.145.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id CC42043D45; Mon, 21 Aug 2006 09:23:52 +0000 (GMT) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (dhartmei@localhost [127.0.0.1]) by insomnia.benzedrine.cx (8.13.4/8.13.4) with ESMTP id k7L9NopT028574 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Mon, 21 Aug 2006 11:23:50 +0200 (MEST) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.13.4/8.12.10/Submit) id k7L9Nofe001713; Mon, 21 Aug 2006 11:23:50 +0200 (MEST) Date: Mon, 21 Aug 2006 11:23:50 +0200 From: Daniel Hartmeier To: Rostislav Krasny Message-ID: <20060821092350.GL20788@insomnia.benzedrine.cx> References: <20060818235756.25f72db4.rosti.bsd@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060818235756.25f72db4.rosti.bsd@gmail.com> User-Agent: Mutt/1.5.10i Cc: freebsd-net@freebsd.org Subject: Re: PF or "traceroute -e -P TCP" bug? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2006 09:23:53 -0000 [ I'm CC'ing Crist, maybe he can explain why -e behaves like it does ] On Fri, Aug 18, 2006 at 11:57:56PM +0300, Rostislav Krasny wrote: > I've tried the new "-e" traceroute option on today's RELENG_6 and > found following problem: > > > traceroute -nq 1 -e -P TCP -p 80 216.136.204.117 As I understand the -e option, that should send a sequence of TCP SYNs with - constant source port (randomly picked per invokation) - constant destination port 80 - increasing TTL per probe Assuming you pass the packets with pf, it matters whether you create state or not. Filtering statelessly (without 'keep state'), there should be no problem at all. I assume you're filtering statefully. With constant source and destination ports, the first probe should create a state entry and all further probes (of the same traceroute invokation) should match that state entry. What you changed in your patch is switching to a sequential (instead of constant) source port. This forces creation of one state per probe, treating each probe as a separate connection. I don't think that's in the spirit of the -e option. There's really no need for that, once the underlying problem is fixed. So, why doesn't -e without your patch produce probes that all match a single state entry? Look at how the TCP sequence numbers are generated across the probes: tcp->th_seq = (tcp->th_sport << 16) | (tcp->th_dport + (fixedPort ? outdata->seq : 0)); This is the problem. traceroute increments the sequence number with each probe. I don't know why that is done. Why not use the same th_seq for all probes, like an ISN (initial sequence number) would be re-used in retransmissions in a real TCP handshake? If you create state on the first TCP SYN pf sees, pf will note the ISN from the traceroute side. When pf sees further SYNs from that side, it will deal with them like with any client retransmitting the SYN of the handshake (before the peer replies with a SYN+ACK, giving its side's ISN). Subsequent TCP SYNs with different ISN matching the address/port pairs will be blocked by pf. If this happens on the IP forwarding path (i.e. pf blocks the packet outgoing), the stack produces the ICMP host unreachable error that shows up as "!H" in traceroute. I assume you have a "pass out on $ext_if keep state" rule, and don't filter on the internal interface. If you add stateful filtering on the internal interface, I think you'll find that subsequent TCP SYNs are blocked without eliciting the ICMP error. I suggest traceroute with -e uses fixed th_seq, as in - tcp->th_seq = (tcp->th_sport << 16) | (tcp->th_dport + - (fixedPort ? outdata->seq : 0)); + tcp->th_seq = (tcp->th_sport << 16) tcp->th_dport; Maybe the (fixedPort?:) operands were mistakenly switched, and you want to increment th_seq when -e is NOT used, but I can't think off-hand why you would. Daniel From owner-freebsd-net@FreeBSD.ORG Mon Aug 21 11:43:28 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 027AC16A4E1 for ; Mon, 21 Aug 2006 11:43:28 +0000 (UTC) (envelope-from gowda_asha2k@yahoo.com) Received: from web33401.mail.mud.yahoo.com (web33401.mail.mud.yahoo.com [68.142.206.133]) by mx1.FreeBSD.org (Postfix) with SMTP id 8271943D4C for ; Mon, 21 Aug 2006 11:43:27 +0000 (GMT) (envelope-from gowda_asha2k@yahoo.com) Received: (qmail 3496 invoked by uid 60001); 21 Aug 2006 11:43:26 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=EBD6wxxT508I3I7G+CxJkxczMS5HV/yCuXCnrYL5/m2qcbfS40H3hpGjgFlYcIrJl5A7DKgrCLQSvwfu8qMiXv2DIYpAkXqpcXPa/UcTfpJGLp0YawISQ1SEKtKcInS7XAED0+NUdD4Sn2K0RbmFwtmKSvHGmReJnc6eQIh+ZD4= ; Message-ID: <20060821114326.3494.qmail@web33401.mail.mud.yahoo.com> Received: from [203.145.176.37] by web33401.mail.mud.yahoo.com via HTTP; Mon, 21 Aug 2006 04:43:26 PDT Date: Mon, 21 Aug 2006 04:43:26 -0700 (PDT) From: ASHA GOWDA To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Mon, 21 Aug 2006 11:51:05 +0000 Subject: Re: Need Information about open source traffic generators 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, 21 Aug 2006 11:43:28 -0000 Hi, We need to test network processor and for this we have to test some application like MLPPP, MLFR, etc. Is there any freely available traffic generators are available . Thanks in advance, Asha __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-freebsd-net@FreeBSD.ORG Mon Aug 21 13:01:31 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C377016A4E2 for ; Mon, 21 Aug 2006 13:01:31 +0000 (UTC) (envelope-from julienabeille@yahoo.fr) Received: from web26608.mail.ukl.yahoo.com (web26608.mail.ukl.yahoo.com [217.146.176.58]) by mx1.FreeBSD.org (Postfix) with SMTP id 211EB43D45 for ; Mon, 21 Aug 2006 13:01:23 +0000 (GMT) (envelope-from julienabeille@yahoo.fr) Received: (qmail 29738 invoked by uid 60001); 21 Aug 2006 13:01:22 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.fr; h=Message-ID:Received:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=P1aONSPKMMsuLyl2lpAHFrzBGsScXYQv3A5ntRCD+4QSGKHDxxNZ0JTFUlwQiTOs1NjaewOm9Fcz2D5cw4jSsWebR+jRuT61LxFTnePAk0kTID5dPKksJiGc1Gf7AFIkbtZpYHvuZgt6w0pFC5xDXWpL6Nq7kBJTU0vCYw99JdE= ; Message-ID: <20060821130122.29736.qmail@web26608.mail.ukl.yahoo.com> Received: from [195.37.70.39] by web26608.mail.ukl.yahoo.com via HTTP; Mon, 21 Aug 2006 13:01:22 GMT Date: Mon, 21 Aug 2006 13:01:22 +0000 (GMT) From: =?iso-8859-1?q?Julien=20Abeill=E9?= To: "freebsd-net@freebsd.org" MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Tr : Re : Re : ipv6 in ipv6 tunnel with FreeBSD 4.11 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?iso-8859-1?q?Julien=20Abeill=E9?= List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2006 13:01:31 -0000 ----- Message transf=E9r=E9 ---- De : Julien Abeill=E9 =C0 : gnn@freebsd.org Envoy=E9 le : Lundi, 21 Ao=FBt 2006, 12h05mn 49s Objet : Re : Re : ipv6 in ipv6 tunnel with FreeBSD 4.11 Hi George, all, I finally found the problem. net.inet6.ip6.gifhlim is set to 0 by default. = Maybe it is because of kame version which is from 2001on 4.11 release. Thanks anyway. Julien ----- Message d'origine ---- De : gnn@freebsd.org =C0 : Julien Abeill=E9 Cc : freebsd-net@freebsd.org Envoy=E9 le : Samedi, 19 Ao=FBt 2006, 2h41mn 22s Objet : Re: Re : ipv6 in ipv6 tunnel with FreeBSD 4.11 At Sat, 19 Aug 2006 11:45:13 +0000 (GMT), Julien Abeill=E9 wrote: >=20 > Hi George, > =20 > thanks for your answer. A few precisions then: I do two setups in > fact, one on IMUNES network emulator (this is why I use FreeBSD > 4.11), one with 4 real machines. The one with four real machines has > no tunnel endpoint. I know it is a bit weard, but the other machines > are linux machines, and I did not want to go in compatibility > problems (if there are some?). I don't know if there are compatability issues with Linux but I doubt it as the same people developed the protocol stacks, at least initially. > On this testbed (with the real machines), I just send trafic from M3 > through the FreeBSD machine. I did not set > ipv6_gateway_enable=3D"YES", but use sysctl. I do not have a BSD here > (internet cafe) so i do not remember the exact parameter > (net.inet6.ip6.forwarding?) but i set ipv6 forwarding to one and > without tunnels I can ping from one end to the other. One question: > are the two tunnel endpoints supposed to negociate something? If > yes, I do need another endpoint. Nope, they don't need to negotiate anything, the machines are just acting as routers. You also need to have appropriate routes set. > In the IMUNES simulation, I have the 4 machines inline the same way > (M1 M2 M3 M4 ) and setup the tunnel on M2 and M3 (between b::1 and > b::2). It works but with hop count limit=3D0. I did the same setup > with 5 machines inline (M1 M2 M3 M4 M5) and a tunnel between M2 and > M4. It does not work anymore: if i send trafic through the tunnel > from M2 to M4, M3 discards the packets and sends an icmpv6 "time > exceeded..." message to M2. > =20 That is odd, but it may be that one of the machines is considering the next hop address to be link local, and not global, in which case it might set the hop limit to be 1, and then it would be decremented to 0 at the other end of the tunnel. Make sure you're not using link local addresses on your tunnel endpoints. > I will try on monday without giving an IPv6 address to the gif > interface. Indeed I followed the instructions on the FreeBSD > handbook section IPv6 for IPv6 in IPv4 tunnels. The problem is I did > not find any instructions for IPv6 in IPv6. The only thing I found > in kame was: "be careful with IPv6 in IPv6 and IPv4 in IPv4 tunnels > which often result in infinite routing in the kernel". Maybe it is > what is happening here. It could be, but I don't have a setup like that to test. You might also ask on the kame-snap@kame.net mailing list as well. Also, keep freebsd-net@freebsd.org cc'd as someone else might be able to answer this better than I. Later, George _______________________________________________ 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 Mon Aug 21 13:05:22 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5A60B16A4E0 for ; Mon, 21 Aug 2006 13:05:22 +0000 (UTC) (envelope-from julienabeille@yahoo.fr) Received: from web26602.mail.ukl.yahoo.com (web26602.mail.ukl.yahoo.com [217.146.176.52]) by mx1.FreeBSD.org (Postfix) with SMTP id 0ACA743D60 for ; Mon, 21 Aug 2006 13:05:19 +0000 (GMT) (envelope-from julienabeille@yahoo.fr) Received: (qmail 39883 invoked by uid 60001); 21 Aug 2006 13:05:19 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.fr; h=Message-ID:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=TZfHJ15QGgRRYuJer5tjRUlGpPtfS1V0WV0psgaaOL9jCJEDC9GW6mIhhj8mii5TV5nIujjfB2rm19X/kdZygdM0q2QRv5U+2dRHA3sGVOt7Ky0R/N8v0J6bqtSQB+t2NMtKeTTYXpwwHP8Db4S0ucChiEWkPUtzTgwJQYHLFag= ; Message-ID: <20060821130519.39881.qmail@web26602.mail.ukl.yahoo.com> Received: from [195.37.70.39] by web26602.mail.ukl.yahoo.com via HTTP; Mon, 21 Aug 2006 13:05:19 GMT Date: Mon, 21 Aug 2006 13:05:19 +0000 (GMT) From: =?iso-8859-1?q?Julien=20Abeill=E9?= To: ASHA GOWDA , freebsd-net@freebsd.org In-Reply-To: <20060821114326.3494.qmail@web33401.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re : Need Information about open source traffic generators X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?iso-8859-1?q?Julien=20Abeill=E9?= List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2006 13:05:22 -0000 Hi Asha, you have many traffic generators in the benchmark ports directory (http://w= ww.freebsd.org/ports/benchmarks.html). I do not know what you are looking for exactly, I was and am sometimes usin= g Iperf, which is a simple tcp/udp traffic generator supporting IPv4/6. Best regards, Julien ----- Message d'origine ---- De : ASHA GOWDA =C0 : freebsd-net@freebsd.org Envoy=E9 le : Lundi, 21 Ao=FBt 2006, 1h43mn 26s Objet : Re: Need Information about open source traffic generators Hi, =20 We need to test network processor and for this we have to test some application like MLPPP, MLFR, etc. Is there any freely available traffic generators are available . =20 Thanks in advance, Asha =20 __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around=20 http://mail.yahoo.com=20 _______________________________________________ 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 Mon Aug 21 15:10:14 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C2D1716A4E7 for ; Mon, 21 Aug 2006 15:10:14 +0000 (UTC) (envelope-from rosti.bsd@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.186]) by mx1.FreeBSD.org (Postfix) with ESMTP id 17B2A43D5A for ; Mon, 21 Aug 2006 15:10:11 +0000 (GMT) (envelope-from rosti.bsd@gmail.com) Received: by nf-out-0910.google.com with SMTP id n29so2107272nfc for ; Mon, 21 Aug 2006 08:10:11 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer:mime-version:content-type:content-transfer-encoding; b=JGwOFqpgv9EGbKNf5tVp7caz+kQUTitrO5k15JCsFhcAnmK87gXaX4d2h7JCKKsugD+NuOaVDMlm5HGtLxUQjqnqgKjVa+va4rVemDUmiFZZSCgtYCRJIl9qtWomgIgybcbZrgojrxa24oFKH949LVta9pqRD7dz2nxnFYRpUoo= Received: by 10.49.90.4 with SMTP id s4mr7815458nfl; Mon, 21 Aug 2006 08:10:11 -0700 (PDT) Received: from saturn.lan ( [212.143.154.227]) by mx.gmail.com with ESMTP id 37sm54556hua.2006.08.21.08.10.08; Mon, 21 Aug 2006 08:10:10 -0700 (PDT) Date: Mon, 21 Aug 2006 18:09:45 +0300 From: Rostislav Krasny To: Daniel Hartmeier Message-Id: <20060821180945.6a75bc44.rosti.bsd@gmail.com> In-Reply-To: <20060821092350.GL20788@insomnia.benzedrine.cx> References: <20060818235756.25f72db4.rosti.bsd@gmail.com> <20060821092350.GL20788@insomnia.benzedrine.cx> X-Mailer: Sylpheed version 2.2.7 (GTK+ 2.8.20; i386-portbld-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: PF or "traceroute -e -P TCP" bug? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2006 15:10:14 -0000 On Mon, 21 Aug 2006 11:23:50 +0200 Daniel Hartmeier wrote: > [ I'm CC'ing Crist, maybe he can explain why -e behaves like it does ] > > On Fri, Aug 18, 2006 at 11:57:56PM +0300, Rostislav Krasny wrote: > > > I've tried the new "-e" traceroute option on today's RELENG_6 and > > found following problem: > > > > > traceroute -nq 1 -e -P TCP -p 80 216.136.204.117 > > As I understand the -e option, that should send a sequence of TCP SYNs > with > > - constant source port (randomly picked per invokation) > - constant destination port 80 > - increasing TTL per probe > > Assuming you pass the packets with pf, it matters whether you create > state or not. Filtering statelessly (without 'keep state'), there should > be no problem at all. I assume you're filtering statefully. I don't use 'keep state' in any pf rule. But I use a nat rule like this: nat on $ext_if from $internal_net to any -> ($ext_if) and according to 'pfctl -s state' any NAT-ed TCP connection creates a state. For example, during the above traceroute: self tcp 192.168.1.2:34345 -> xxx.xxx.xxx.xxx:50646 -> 216.136.204.117:80 SYN_SENT:CLOSED > With constant source and destination ports, the first probe should > create a state entry and all further probes (of the same traceroute > invokation) should match that state entry. > > What you changed in your patch is switching to a sequential (instead of > constant) source port. This forces creation of one state per probe, > treating each probe as a separate connection. Correct. > I don't think that's in > the spirit of the -e option. There's really no need for that, once the > underlying problem is fixed. > > So, why doesn't -e without your patch produce probes that all match a > single state entry? By the way, I asked a friend from IRC to try "traceroute -e -P TCP" through his router which does NATing by natd and it worked there. > Look at how the TCP sequence numbers are generated across the probes: > > tcp->th_seq = (tcp->th_sport << 16) | (tcp->th_dport + > (fixedPort ? outdata->seq : 0)); > > This is the problem. traceroute increments the sequence number with each > probe. I don't know why that is done. Why not use the same th_seq for > all probes, like an ISN (initial sequence number) would be re-used in > retransmissions in a real TCP handshake? > > If you create state on the first TCP SYN pf sees, pf will note the ISN > from the traceroute side. When pf sees further SYNs from that side, it > will deal with them like with any client retransmitting the SYN of the > handshake (before the peer replies with a SYN+ACK, giving its side's > ISN). Subsequent TCP SYNs with different ISN matching the address/port > pairs will be blocked by pf. > > If this happens on the IP forwarding path (i.e. pf blocks the packet > outgoing), the stack produces the ICMP host unreachable error that shows > up as "!H" in traceroute. I assume you have a "pass out on $ext_if keep > state" rule, and don't filter on the internal interface. If you add > stateful filtering on the internal interface, I think you'll find that > subsequent TCP SYNs are blocked without eliciting the ICMP error. > > I suggest traceroute with -e uses fixed th_seq, as in > > - tcp->th_seq = (tcp->th_sport << 16) | (tcp->th_dport + > - (fixedPort ? outdata->seq : 0)); > + tcp->th_seq = (tcp->th_sport << 16) tcp->th_dport; Even if I add accidentally deleted '|' it doesn't fix the problem: > traceroute -nq 1 -e -P TCP -p 80 www.freebsd.org traceroute to www.freebsd.org (216.136.204.117), 64 hops max, 52 byte packets 1 192.168.1.1 0.525 ms 2 10.0.0.138 2.122 ms 3 * 4 * 5 * 6 * 7 * 8 * 9 * 10 152.63.3.122 191.562 ms 11 * 12 * ^C I can decrease number of the "*" hops by -w option: > traceroute -nq 1 -e -w 10 -P TCP -p 80 www.freebsd.org traceroute to www.freebsd.org (216.136.204.117), 64 hops max, 52 byte packets 1 192.168.1.1 0.506 ms 2 10.0.0.138 1.886 ms 3 * 4 * 5 * 6 * 7 212.143.12.45 151.282 ms 8 * ^C According to repeatedly ran 'pfctl -s state | grep 216.136.204.117' it really has some relation to TCP states in the pf. Before the 212.143.12.45 hop the state closed and after that hop a new state created. And by the way, I think a tcp_check() function checks tcp->th_seq incorrectly: tcp->th_seq == (ident << 16) | (port + seq) In original version or after my patch it should be changed to this: tcp->th_seq == (htons(ident) << 16) | (port + (fixedPort ? seq : 0)) and after your patch to this: tcp->th_seq == (htons(ident) << 16) | port It looks like the return value of the tcp_check() isn't used anywhere anyway. From owner-freebsd-net@FreeBSD.ORG Mon Aug 21 16:27:54 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5BB3D16A4DA; Mon, 21 Aug 2006 16:27:54 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 70DEE43D4C; Mon, 21 Aug 2006 16:27:53 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp5-g19.free.fr (Postfix) with ESMTP id 7C263260AA; Mon, 21 Aug 2006 18:27:52 +0200 (CEST) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id 754AE9C323; Mon, 21 Aug 2006 16:28:30 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id 39F0F405B; Mon, 21 Aug 2006 18:28:30 +0200 (CEST) Date: Mon, 21 Aug 2006 18:28:30 +0200 From: Jeremie Le Hen To: Andrew Pantyukhin Message-ID: <20060821162830.GA58048@obiwan.tataz.chchile.org> References: <44E58E9E.1030401@FreeBSD.org> <44E5F19E.9070600@isi.edu> <44E619F7.7030300@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.12-2006-07-14 Cc: remko@freebsd.org, thompsa@FreeBSD.org, net@freebsd.org Subject: Re: [fbsd] Re: Routing IPSEC packets? 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, 21 Aug 2006 16:27:54 -0000 Hi Andrew, On Fri, Aug 18, 2006 at 11:58:08PM +0400, Andrew Pantyukhin wrote: > I'm actually trying to marry FreeBSD to PIX. The latter only > supports IPSec (tunnel/transport). I'm still struggling with > firewalls on both sides, but tunnel-tunnel works right now. > I'm a bit puzzled because the howto I see > (http://www.bshell.com/projects/freebsd_pix/) uses gif(4) > with tunnel-mode IPSec. Either something is wrong with > the way things work or the author doesn't understand what > he's doing (or both). The bitter thing is that we have a > similar setup in our handbook: > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ipsec.html The handbook is known to be wrong for this. ISTR there have been some mails around there about the incorrectness of the latter page. See the following URL: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=236856+0+archive/2001/freebsd-net/20010506.freebsd-net And this recent thread that shows how much the documentation is deceiving: http://lists.freebsd.org/pipermail/freebsd-net/2005-December/009322.html I have already been misleaded by the IPSec tunnel mode + gif(4) setup, and it happens that though everything appears to work well, traffic won't go through your gif(4) interface, which is useless (you can check this with tcpdump(8)). I think you can simply try to remove it in this case, or set it down, and your tunnel should continue to work correctly. This has already been reported in this thread: http://lists.freebsd.org/pipermail/freebsd-security/2003-October/001135.html If you succeed to you both IPSec tunneling mode and gif(4), you will have a double-encapsulation. Basically, you will get something like this: [ IP ] [ IP ] [ IPSec ] [ IP ] As is has indeed already been stated in this thread, IPSec tunnel mode shunts the routing table. However the new enc(4) interface that Andrew Thompson has imported from OpenBSD allows to filter IPSec traffic in a more natural way. Maybe it also brings the ability to route IPSec tunnels, or even bridge them with if_bridge(4). I Cc'ed him for clarification. I hope this mail will serve future generations :-). Best regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-net@FreeBSD.ORG Mon Aug 21 16:46:02 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6217816A4DA for ; Mon, 21 Aug 2006 16:46:02 +0000 (UTC) (envelope-from infofarmer@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.178]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D12743D76 for ; Mon, 21 Aug 2006 16:45:55 +0000 (GMT) (envelope-from infofarmer@gmail.com) Received: by py-out-1112.google.com with SMTP id o67so2481110pye for ; Mon, 21 Aug 2006 09:45:54 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=DAIC3Eblz/VWP8St8eYKr6fovtYMgsQmgAbQLjQI4mjZCHPsPHwUT+ruAGNGEtKlGSchTkwGI8lqotFE0aGEZFWpgFiAaIHiGd3RxfOWi/fqkCV8sRvg62DDCc+0gVL6Gr2n2i1MarfxeUa6Ey8Aj60PTqckZQrHRFun8lpeuWc= Received: by 10.35.126.7 with SMTP id d7mr13663606pyn; Mon, 21 Aug 2006 09:45:54 -0700 (PDT) Received: by 10.35.105.10 with HTTP; Mon, 21 Aug 2006 09:45:54 -0700 (PDT) Message-ID: Date: Mon, 21 Aug 2006 20:45:54 +0400 From: "Andrew Pantyukhin" Sender: infofarmer@gmail.com To: "Jeremie Le Hen" In-Reply-To: <20060821162830.GA58048@obiwan.tataz.chchile.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <44E58E9E.1030401@FreeBSD.org> <44E5F19E.9070600@isi.edu> <44E619F7.7030300@isi.edu> <20060821162830.GA58048@obiwan.tataz.chchile.org> X-Google-Sender-Auth: 71a00aa4b6b0cf94 Cc: remko@freebsd.org, thompsa@freebsd.org, net@freebsd.org Subject: Re: [fbsd] Re: Routing IPSEC packets? 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, 21 Aug 2006 16:46:02 -0000 On 8/21/06, Jeremie Le Hen wrote: > As is has indeed already been stated in this thread, IPSec tunnel mode > shunts the routing table. However the new enc(4) interface that Andrew > Thompson has imported from OpenBSD allows to filter IPSec traffic in a > more natural way. My understanding is that "options IPSEC_FILTERGIF" already forces decoded packets to show up on the interface: http://lists.freebsd.org/pipermail/freebsd-bugs/2005-December/016074.html From owner-freebsd-net@FreeBSD.ORG Mon Aug 21 16:49:54 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3575016A4DF; Mon, 21 Aug 2006 16:49:54 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp3-g19.free.fr (smtp3-g19.free.fr [212.27.42.29]) by mx1.FreeBSD.org (Postfix) with ESMTP id BCD5D43D5D; Mon, 21 Aug 2006 16:49:48 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp3-g19.free.fr (Postfix) with ESMTP id 1BD0049927; Mon, 21 Aug 2006 18:49:48 +0200 (CEST) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id 1654E9C329; Mon, 21 Aug 2006 16:50:26 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id F0218405B; Mon, 21 Aug 2006 18:50:25 +0200 (CEST) Date: Mon, 21 Aug 2006 18:50:25 +0200 From: Jeremie Le Hen To: Andrew Pantyukhin Message-ID: <20060821165025.GB58048@obiwan.tataz.chchile.org> References: <44E58E9E.1030401@FreeBSD.org> <44E5F19E.9070600@isi.edu> <44E619F7.7030300@isi.edu> <20060821162830.GA58048@obiwan.tataz.chchile.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.12-2006-07-14 Cc: net@freebsd.org Subject: Re: [fbsd] Re: Routing IPSEC packets? 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, 21 Aug 2006 16:49:54 -0000 Anndrew, On Mon, Aug 21, 2006 at 08:45:54PM +0400, Andrew Pantyukhin wrote: > On 8/21/06, Jeremie Le Hen wrote: > >As is has indeed already been stated in this thread, IPSec tunnel mode > >shunts the routing table. However the new enc(4) interface that Andrew > >Thompson has imported from OpenBSD allows to filter IPSec traffic in a > >more natural way. > > My understanding is that "options IPSEC_FILTERGIF" > already forces decoded packets to show up on the > interface: > > http://lists.freebsd.org/pipermail/freebsd-bugs/2005-December/016074.html I agree with this, that's why I said "... allows to filter IPSec traffic _in a more natural way_". IPSEC_FILTERGIF is a kind of hack IMHO, though it has revealed itself to be very useful for many years. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-net@FreeBSD.ORG Mon Aug 21 16:54:07 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 872E416A4DD for ; Mon, 21 Aug 2006 16:54:07 +0000 (UTC) (envelope-from baldur@foo.is) Received: from gremlin.foo.is (gremlin.foo.is [194.105.250.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4022F43D6D for ; Mon, 21 Aug 2006 16:54:04 +0000 (GMT) (envelope-from baldur@foo.is) Received: from 127.0.0.1 (localhost.foo.is [127.0.0.1]) by injector.foo.is (Postfix) with SMTP id 828CADA844 for ; Mon, 21 Aug 2006 16:54:03 +0000 (GMT) Received: by gremlin.foo.is (Postfix, from userid 1000) id 1402DDA86B; Mon, 21 Aug 2006 16:54:01 +0000 (GMT) Date: Mon, 21 Aug 2006 16:54:01 +0000 From: Baldur Gislason To: freebsd-net@freebsd.org Message-ID: <20060821165401.GB804@gremlin.foo.is> User-Agent: Mutt/1.4.2.1i X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on gremlin.foo.is X-Spam-Level: X-Spam-Status: No, score=-5.9 required=6.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 X-Sanitizer: Foo MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Subject: Multicast 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, 21 Aug 2006 16:54:07 -0000 I'm having some problems receiving multicast traffic on my FreeBSD 6.1-STABLE workstation with VLC. I get the streams but I seem to get plenty of packetloss on the freebsd box but on other boxes on the same network I don't see such problems. I haven't noticed any packetloss with unicast. Any thoughts? I've tried running a GENERIC kernel and that makes no difference, I've also tried two different network cards. (em and fxp) Baldur From owner-freebsd-net@FreeBSD.ORG Mon Aug 21 18:21:18 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 584DA16A605 for ; Mon, 21 Aug 2006 18:21:17 +0000 (UTC) (envelope-from fli+freebsd-net@shapeshifter.se) Received: from mx1.h3q.net (manticore.shapeshifter.se [212.37.5.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id DB56B43D46 for ; Mon, 21 Aug 2006 18:21:14 +0000 (GMT) (envelope-from fli+freebsd-net@shapeshifter.se) Received: from localhost (localhost [127.0.0.1]) by mx1.h3q.net (Postfix) with ESMTP id 3E1911A78D for ; Mon, 21 Aug 2006 20:21:12 +0200 (CEST) Received: from mx1.h3q.net ([127.0.0.1]) by localhost (mx1.h3q.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57784-07 for ; Mon, 21 Aug 2006 20:21:09 +0200 (CEST) Received: from [192.168.1.100] (217-208-33-252-o926.tbon.telia.com [217.208.33.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.h3q.net (Postfix) with ESMTP id 458FB1A72A for ; Mon, 21 Aug 2006 20:21:09 +0200 (CEST) Message-ID: <44E9F991.7020309@shapeshifter.se> Date: Mon, 21 Aug 2006 20:21:05 +0200 From: Fredrik Lindberg User-Agent: Thunderbird 1.5.0.4 (X11/20060727) 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-Scanned: amavisd-new at h3q.net Subject: Zeroconfig and Multicast DNS 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, 21 Aug 2006 18:21:18 -0000 Hi all, A while ago I started hacking on a zeroconfig and multicast DNS implementation for FreeBSD. In short, zeroconfig allows a host to automatically negotiate a collision free ip-address with other hosts on the network in the absence of a DHCP-server. It's suitable for small ad-hoc networks, or in embedded solutions. Multicast DNS is DNS without a server, you can think of it as mixing P2P and DNS. There are no authoritative server, instead all peers co-operate to resolve queries. This also means that any host can choose any name (collision detect is a part of the protocol). The end result is that hosts on a local network can communicate with each other by name without the need of a central DNS-server and without the need of having prior knowledge of each other (/etc/hosts etc). Suitable in networks without a dedicated name server and of course in embedded solutions (ie. communicate directly with that "black box" using a name instead of some pre-configured ip-address). I've now reached a point where the daemons/libraries/tools actually do what they are supposed (at least more or less...). zeroconfd is more or less complete and should work just fine. responderd is able to do most of the critical things it's suppose to do (resolve/cache names), however there are some things left such as TCP fall back for unicast queries, INET6 needs to be implemented properly (the framework has support for INET6, just needs some work), also, the probe/collision routines are currently missing. More information, code and some quick starting hints are available at http://shapeshifter.se/projects/freebsd/zeroconfig/ Fredrik Lindberg From owner-freebsd-net@FreeBSD.ORG Mon Aug 21 19:54:40 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AB67616A522 for ; Mon, 21 Aug 2006 19:54:40 +0000 (UTC) (envelope-from patl+freebsd@volant.org) Received: from smtp.volant.org (gate.volant.org [207.111.218.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id A44B143D46 for ; Mon, 21 Aug 2006 19:54:22 +0000 (GMT) (envelope-from patl+freebsd@volant.org) Received: from adsl-065-081-071-131.sip.gnv.bellsouth.net ([65.81.71.131] helo=[192.168.1.121]) by smtp.volant.org with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34 (FreeBSD)) id 1GFFr0-00011Q-7E; Mon, 21 Aug 2006 12:57:39 -0700 Date: Mon, 21 Aug 2006 12:50:14 -0400 From: Pat Lashley To: Fredrik Lindberg , freebsd-net@freebsd.org Message-ID: In-Reply-To: <44E9F991.7020309@shapeshifter.se> References: <44E9F991.7020309@shapeshifter.se> X-Mailer: Mulberry/4.0.0 (Mac OS X) MIME-Version: 1.0 X-Scan-Signature: 34689b30fd35368c46f018b3f3e3df493d3bfb2a X-Spam-User: nobody X-Spam-Score: -4.1 (----) X-Spam-Score-Int: -40 X-Spam-Report: This mail has matched the spam-filter tests listed below. See http://spamassassin.org/tag/ for details about the specific tests reported. In general, the higher the number of total points, the more likely that it actually is spam. (The 'required' number of points listed below is the arbitrary number above which the message is normally considered spam.) Content analysis details: (-4.1 points total, 5.0 required) 0.1 HTML_MESSAGE BODY: HTML included in message 0.1 HTML_FONTCOLOR_RED BODY: HTML font color is red -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0009] 0.4 DATE_IN_PAST_03_06 Date: is 3 to 6 hours before Received: date 0.2 AWL AWL: Auto-whitelist adjustment Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: Zeroconfig and Multicast DNS 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, 21 Aug 2006 19:54:40 -0000 > In short, zeroconfig allows a host to automatically negotiate > a collision free ip-address with other hosts on the network in the > absence of a DHCP-server. It's suitable for small ad-hoc networks, > or in embedded solutions. Actually, that is IPv4 Link Local Addressing. Zeroconfig includes that, Multicast DNS, Service Discovery and anything else that removes the need for manual configuration. I'm very glad to hear that somebody is working on IPv4 Link Local for FreeBSD. > Multicast DNS is DNS without a server, you can think of it as mixing > ... Doesn't the net/mDNSResponder port handle both mDNS and (m)DNS-based service discovery? Is it missing some functionality that can't be easily handled by a wrapper? (E.g. An nss_mdns that uses their libdns_sd.so) -Pat From owner-freebsd-net@FreeBSD.ORG Mon Aug 21 19:56:34 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3D65016A50C for ; Mon, 21 Aug 2006 19:56:34 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 81E1043D70 for ; Mon, 21 Aug 2006 19:56:05 +0000 (GMT) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k7LJtTEh062569 for ; Mon, 21 Aug 2006 19:55:29 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k7LJtSdA062564 for freebsd-net@FreeBSD.org; Mon, 21 Aug 2006 19:55:28 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 21 Aug 2006 19:55:28 GMT Message-Id: <200608211955.k7LJtSdA062564@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: linimon set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to you 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, 21 Aug 2006 19:56:34 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/92552 net A serious bug in most network drivers from 5.X to 6.X f kern/93220 net [inet6] nd6_lookup: failed to add route for a neighbor o kern/100172 net [arp] Transfer of large file fails with host is down m 3 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- s kern/19875 net A new protocol family, PF_IPOPTION, to handle IP optio o conf/23063 net [PATCH] for static ARP tables in rc.network s kern/31686 net Problem with the timestamp option when flag equals zer 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 o kern/102035 net [plip] plip networking disables parallel port printing 7 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Aug 21 20:03:29 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2C68C16A4EB for ; Mon, 21 Aug 2006 20:03:29 +0000 (UTC) (envelope-from cristjc@comcast.net) Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.152]) by mx1.FreeBSD.org (Postfix) with ESMTP id D4B4843DC5 for ; Mon, 21 Aug 2006 20:00:17 +0000 (GMT) (envelope-from cristjc@comcast.net) Received: from goku.cjclark.org (c-24-6-168-219.hsd1.ca.comcast.net[24.6.168.219]) by comcast.net (rwcrmhc12) with ESMTP id <20060821195941m1200sfifee>; Mon, 21 Aug 2006 19:59:42 +0000 Received: from goku.cjclark.org (localhost. [127.0.0.1]) by goku.cjclark.org (8.13.3/8.12.8) with ESMTP id k7LJxftE023088; Mon, 21 Aug 2006 12:59:43 -0700 (PDT) (envelope-from cristjc@comcast.net) Received: (from cjc@localhost) by goku.cjclark.org (8.13.3/8.13.1/Submit) id k7LJxdCY023083; Mon, 21 Aug 2006 12:59:39 -0700 (PDT) (envelope-from cristjc@comcast.net) X-Authentication-Warning: goku.cjclark.org: cjc set sender to cristjc@comcast.net using -f Date: Mon, 21 Aug 2006 12:59:38 -0700 From: "Crist J. Clark" To: Daniel Hartmeier Message-ID: <20060821195938.GA16332@goku.cjclark.org> References: <20060818235756.25f72db4.rosti.bsd@gmail.com> <20060821092350.GL20788@insomnia.benzedrine.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060821092350.GL20788@insomnia.benzedrine.cx> User-Agent: Mutt/1.4.2.1i X-URL: http://people.freebsd.org/~cjc/ Cc: Rostislav Krasny , freebsd-net@freebsd.org Subject: Re: PF or "traceroute -e -P TCP" bug? 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: Mon, 21 Aug 2006 20:03:29 -0000 On Mon, Aug 21, 2006 at 11:23:50AM +0200, Daniel Hartmeier wrote: > [ I'm CC'ing Crist, maybe he can explain why -e behaves like it does ] > > On Fri, Aug 18, 2006 at 11:57:56PM +0300, Rostislav Krasny wrote: > > > I've tried the new "-e" traceroute option on today's RELENG_6 and > > found following problem: > > > > > traceroute -nq 1 -e -P TCP -p 80 216.136.204.117 > > As I understand the -e option, that should send a sequence of TCP SYNs > with > > - constant source port (randomly picked per invokation) It's actually trivial encoding of the traceroute process ID so that two traceroute programs running simultaenously do not clobber each other. However, this becomes important. > - constant destination port 80 Yes, the whole point of "-e." > - increasing TTL per probe Yes, the basic kludge that makes traceroute work. Here is the basic explanation behind the changes, http://docs.freebsd.org/cgi/getmsg.cgi?fetch=414378+0+archive/2005/freebsd-net/20050925.freebsd-net [snip] > What you changed in your patch is switching to a sequential (instead of > constant) source port. This forces creation of one state per probe, > treating each probe as a separate connection. I don't think that's in > the spirit of the -e option. There's really no need for that, once the > underlying problem is fixed. Creating multiple state entries in a firewall really has no concequence as far as the operation of the "-e" option goes. It doesn't have any affect on the three essential characeristics of the probe that you listed above. > So, why doesn't -e without your patch produce probes that all match a > single state entry? > > Look at how the TCP sequence numbers are generated across the probes: > > tcp->th_seq = (tcp->th_sport << 16) | (tcp->th_dport + > (fixedPort ? outdata->seq : 0)); > > This is the problem. traceroute increments the sequence number with each > probe. I don't know why that is done. Why not use the same th_seq for > all probes, like an ISN (initial sequence number) would be re-used in > retransmissions in a real TCP handshake? 'Cause I needed to include that traceroute sequence number somewhere since it wasn't in the destination port any more. > If you create state on the first TCP SYN pf sees, pf will note the ISN > from the traceroute side. When pf sees further SYNs from that side, it > will deal with them like with any client retransmitting the SYN of the > handshake (before the peer replies with a SYN+ACK, giving its side's > ISN). Subsequent TCP SYNs with different ISN matching the address/port > pairs will be blocked by pf. That may be a little strict on the part of pf. One has to balance the "liberal in what you accept" versus being overly strict in security software. But it would be difficult to come up with a legitimate reason for a host to send SYNs with differing ISNs to the same source-IP-source-port-destination-IP-destination-port-tuple on any timescale less than the MSL. > If this happens on the IP forwarding path (i.e. pf blocks the packet > outgoing), the stack produces the ICMP host unreachable error that shows > up as "!H" in traceroute. I assume you have a "pass out on $ext_if keep > state" rule, and don't filter on the internal interface. If you add > stateful filtering on the internal interface, I think you'll find that > subsequent TCP SYNs are blocked without eliciting the ICMP error. > > I suggest traceroute with -e uses fixed th_seq, as in > > - tcp->th_seq = (tcp->th_sport << 16) | (tcp->th_dport + > - (fixedPort ? outdata->seq : 0)); > + tcp->th_seq = (tcp->th_sport << 16) tcp->th_dport; > > Maybe the (fixedPort?:) operands were mistakenly switched, and you want to > increment th_seq when -e is NOT used, but I can't think off-hand why you > would. The ISNs do increment when the "-e" option is not used since the dport increments. That's why I didn't realize incrementing the SYN might cause new problems. The problem with this patch is that we don't have the sequence number anywhere in the TCP header. (Don't bring up the IP header please. That's a whole 'nother issue.) So, to expand on the three points above, we need (1) fixed destination port, (2) to increment IP TTL, (3) the sequence number encoded in some head field, and (3) a source port chosen so that multiple traceroute invocations do not share any src-sport-dst-dport-tuples during their lifetime. In the past, using the PID worked for the sport, but think about what happens if you start with the PID then start incrementing or decrementing, you get overlaps (unless your system does a decent job with random PIDs; not the default for FreeBSD unfortunately). The patch to freebsd-net addresses these problems. It changes the sorce port so that we don't have overlapping src-sport-dst-dport-tuples, and uses a base source port from the LSBs of the clock for a "random" number. That would seem to fix the problem. The only question would be is that a good way to pick the base source port? It's probably good enough, although some kind of hash of the PID might be better. -- Crist J. Clark | cjclark@alum.mit.edu From owner-freebsd-net@FreeBSD.ORG Mon Aug 21 20:36:01 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4289816A4DA for ; Mon, 21 Aug 2006 20:36:01 +0000 (UTC) (envelope-from fli+freebsd-net@shapeshifter.se) Received: from mx1.h3q.net (manticore.shapeshifter.se [212.37.5.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id E5C3243D46 for ; Mon, 21 Aug 2006 20:35:58 +0000 (GMT) (envelope-from fli+freebsd-net@shapeshifter.se) Received: from localhost (localhost [127.0.0.1]) by mx1.h3q.net (Postfix) with ESMTP id 6ACB81A78D; Mon, 21 Aug 2006 22:35:56 +0200 (CEST) Received: from mx1.h3q.net ([127.0.0.1]) by localhost (mx1.h3q.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60542-02; Mon, 21 Aug 2006 22:35:51 +0200 (CEST) Received: from [192.168.1.100] (217-208-33-252-o926.tbon.telia.com [217.208.33.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.h3q.net (Postfix) with ESMTP id 4645E1A72A; Mon, 21 Aug 2006 22:35:51 +0200 (CEST) Message-ID: <44EA1926.2000501@shapeshifter.se> Date: Mon, 21 Aug 2006 22:35:50 +0200 From: Fredrik Lindberg User-Agent: Thunderbird 1.5.0.4 (X11/20060727) MIME-Version: 1.0 To: Pat Lashley References: <44E9F991.7020309@shapeshifter.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at h3q.net Cc: freebsd-net@freebsd.org Subject: Re: Zeroconfig and Multicast DNS 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, 21 Aug 2006 20:36:01 -0000 Pat Lashley wrote: >> In short, zeroconfig allows a host to automatically negotiate >> a collision free ip-address with other hosts on the network in the >> absence of a DHCP-server. It's suitable for small ad-hoc networks, >> or in embedded solutions. > > Actually, that is IPv4 Link Local Addressing. Zeroconfig includes that, > Multicast DNS, Service Discovery and anything else that removes the need > for manual configuration. Yeah, I actually know that. It's just that I've developed a bad habit of calling it zeroconfig in the absence of a short name, calling it "ipv4 link local addressing" every time tends to get a bit tedious. But I should not have done that in my previous mail, my apologies. > > I'm very glad to hear that somebody is working on IPv4 Link Local for > FreeBSD. > >> Multicast DNS is DNS without a server, you can think of it as mixing >> ... > > Doesn't the net/mDNSResponder port handle both mDNS and (m)DNS-based > service discovery? Is it missing some functionality that can't be easily > handled by a wrapper? (E.g. An nss_mdns that uses their libdns_sd.so) > I didn't know there was a port of Apples daemon and I'm sure it works just fine. The only thing that might be an issue is licensing terms, at least in embedded solutions. My code is under a BSD license. I'll continue to hack on my responder anyway, as it's not that far from completion. The service discovery part is just a set of records in the responder which it responds to, a service discovery client/agent is needed to find announced records. Fredrik Lindberg From owner-freebsd-net@FreeBSD.ORG Mon Aug 21 21:06:55 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 42E8A16A4E1 for ; Mon, 21 Aug 2006 21:06:55 +0000 (UTC) (envelope-from thompsa@freebsd.org) Received: from grunt14.ihug.co.nz (grunt14.ihug.co.nz [203.109.254.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3994F43D55 for ; Mon, 21 Aug 2006 21:06:53 +0000 (GMT) (envelope-from thompsa@freebsd.org) Received: from 203-109-251-39.static.bliink.ihug.co.nz (heff.fud.org.nz) [203.109.251.39] by grunt14.ihug.co.nz with esmtp (Exim 3.35 #1 (Debian)) id 1GFGyp-00065l-00; Tue, 22 Aug 2006 09:06:44 +1200 Received: by heff.fud.org.nz (Postfix, from userid 1001) id 3CF051CC23; Tue, 22 Aug 2006 09:06:43 +1200 (NZST) Date: Tue, 22 Aug 2006 09:06:43 +1200 From: Andrew Thompson To: Jeremie Le Hen Message-ID: <20060821210643.GE90346@heff.fud.org.nz> References: <44E58E9E.1030401@FreeBSD.org> <44E5F19E.9070600@isi.edu> <44E619F7.7030300@isi.edu> <20060821162830.GA58048@obiwan.tataz.chchile.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060821162830.GA58048@obiwan.tataz.chchile.org> User-Agent: Mutt/1.5.11 Cc: remko@freebsd.org, Andrew Pantyukhin , net@freebsd.org Subject: Re: [fbsd] Re: Routing IPSEC packets? 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, 21 Aug 2006 21:06:55 -0000 On Mon, Aug 21, 2006 at 06:28:30PM +0200, Jeremie Le Hen wrote: > Hi Andrew, > > On Fri, Aug 18, 2006 at 11:58:08PM +0400, Andrew Pantyukhin wrote: > > I'm actually trying to marry FreeBSD to PIX. The latter only > > supports IPSec (tunnel/transport). I'm still struggling with > > firewalls on both sides, but tunnel-tunnel works right now. > > I'm a bit puzzled because the howto I see > > (http://www.bshell.com/projects/freebsd_pix/) uses gif(4) > > with tunnel-mode IPSec. Either something is wrong with > > the way things work or the author doesn't understand what > > he's doing (or both). The bitter thing is that we have a > > similar setup in our handbook: > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ipsec.html > > As is has indeed already been stated in this thread, IPSec tunnel mode > shunts the routing table. However the new enc(4) interface that Andrew > Thompson has imported from OpenBSD allows to filter IPSec traffic in a > more natural way. Maybe it also brings the ability to route IPSec > tunnels, or even bridge them with if_bridge(4). I Cc'ed him for clarification. At the moment enc(4) isnt really a real interface and while ipsec traffic seems to pass through it, it actually doesnt. The ipsec code just calls the enc code which does pfil/bpf with a preallocated enc0. Im sure this could be extended to allow routing and other tricks. Andrew From owner-freebsd-net@FreeBSD.ORG Mon Aug 21 21:54:23 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 893A616A4DA for ; Mon, 21 Aug 2006 21:54:23 +0000 (UTC) (envelope-from pawel.worach@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.237]) by mx1.FreeBSD.org (Postfix) with ESMTP id 08BD143D62 for ; Mon, 21 Aug 2006 21:54:22 +0000 (GMT) (envelope-from pawel.worach@gmail.com) Received: by wr-out-0506.google.com with SMTP id 70so311688wra for ; Mon, 21 Aug 2006 14:54:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=JvEXhuJMlm3TElYvnONG/Xy+TSC5k5NGtdCSzXdSmaeCIWjf74k3qvmUNXsDxAqOof6tEfFW+/ThJvNLEttOi1XC2fghkUcoCMpluXsjQ417tfaDnS2tuxFU9UL77yAU8Ckd3EQYKix9dUVmSgJRNAnPJqIQehhklSLWrfi57pg= Received: by 10.90.79.6 with SMTP id c6mr360692agb; Mon, 21 Aug 2006 14:54:22 -0700 (PDT) Received: by 10.90.49.4 with HTTP; Mon, 21 Aug 2006 14:54:22 -0700 (PDT) Message-ID: Date: Mon, 21 Aug 2006 23:54:22 +0200 From: "Pawel Worach" To: net@freebsd.org In-Reply-To: <4331F3A3.1060707@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4330711A.4040808@gmail.com> <4331F3A3.1060707@gmail.com> Cc: Subject: Re: [panic] page fault in tcp_timer_2msl_tw 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, 21 Aug 2006 21:54:23 -0000 On 9/22/05, Pawel Worach wrote: > Pawel Worach wrote: > > > (kgdb) print *tw > > $1 = {tw_inpcb = 0x0, snd_nxt = 438603527, rcv_nxt = 3383864561, > > iss = 438603320, irs = 3383863898, cc_recv = 0, cc_send = 0, > > last_win = 65534, tw_so_options = 4, tw_cred = 0x0, t_recent = 0, > > t_starttime = 4294952294, tw_time = 0, tw_2msl = {le_next = 0xc24680a8, > > le_prev = 0xc06a827c}} > > I poked a bit more and it looks like the dereference happens here in > tcp_timer_2msl_tw(). > > tcp_timer.c:294 INP_LOCK(tw->tw_inpcb); > > INP_LOCK macro tries to reference tw->tw_inpcb->inp_mtx while > tw->tw_inpcb is null. However I have no idea how it got to this point. > Bumped into this one again on 6.1, almost a year ago since last time. So far my conclusion is that it is hard to reproduce :) Anyone has an idea what might be going on ? Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0xac fault code = supervisor write, page not present instruction pointer = 0x20:0xc059291a stack pointer = 0x28:0xe3474bf4 frame pointer = 0x28:0xe3474c20 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 15 (swi4: clock sio) trap number = 12 panic: page fault cpuid = 2 KDB: stack backtrace: kdb_backtrace(c068eecd,2,c06718cd,e3474af8,a) at kdb_backtrace+0x2e panic(c06718cd,c068fa6f,c46c8394,1,1) at panic+0x139 trap_fatal(e3474bb4,ac,2,8,0) at trap_fatal+0x36e trap_pfault(e3474bb4,0,ac,c0c471e0,ac) at trap_pfault+0x242 trap(8,28,c0c40028,0,4) at trap+0x350 calltrap() at calltrap+0x5 --- trap 0xc, eip = 0xc059291a, esp = 0xe3474bf4, ebp = 0xe3474c20 --- tcp_timer_2msl_tw(0,c04f462a,c06ad420,c06ad880,16) at tcp_timer_2msl_tw+0x5a tcp_slowtimo(e3474c5c,c46c9d80,4,e3474c5c,0) at tcp_slowtimo+0x6c pfslowtimo(0,c4826300,c06a5320,ca76356b,c46c82b4) at pfslowtimo+0x39 softclock(0,e3474cd0,831264,61432328,c46c9d80) at softclock+0x366 ithread_execute_handlers(c46c820c,c4725c00,0,0,0) at ithread_execute_handlers+0x178 ithread_loop(c46af8c0,e3474d38,0,0,0) at ithread_loop+0x77 fork_exit(c04c2180,c46af8c0,e3474d38) at fork_exit+0x80 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe3474d6c, ebp = 0 --- Uptime: 99d10h5m26s Dumping 1023 MB (2 chunks) chunk 0: 1MB (157 pages) ... ok chunk 1: 1023MB (261851 pages) 1007 991 975 959 943 927 911 895 879 863 847 831 815 799 783 767 751 735 719 703 687 671 655 639 623 607 591 575 559 543 527 511 495 479 463 447 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15 #0 doadump () at pcpu.h:165 165 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:165 #1 0xc04dde2c in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:402 #2 0xc04de253 in panic (fmt=0xc06718cd "%s") at /usr/src/sys/kern/kern_shutdown.c:558 #3 0xc065481e in trap_fatal (frame=0xe3474bb4, eva=0) at /usr/src/sys/i386/i386/trap.c:836 #4 0xc0654482 in trap_pfault (frame=0xe3474bb4, usermode=0, eva=172) at /usr/src/sys/i386/i386/trap.c:744 #5 0xc0653ff0 in trap (frame= {tf_fs = 8, tf_es = 40, tf_ds = -1060896728, tf_edi = 0, tf_esi = 4, tf_ebp = -481866720, tf_isp = -481866784, tf_ebx = -966999536, tf_edx = -1060867608, tf_ecx = -999514752, tf_eax = 4, tf_trapno = 12, tf_err = 2, tf_eip = -1067898598, tf_cs = 32, tf_eflags = 66195, tf_esp = -966999536, tf_ss = 0}) at /usr/src/sys/i386/i386/trap.c:434 #6 0xc063e18a in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #7 0xc059291a in tcp_timer_2msl_tw (reuse=0) at atomic.h:149 #8 0xc05922ac in tcp_slowtimo () at /usr/src/sys/netinet/tcp_timer.c:116 #9 0xc0522879 in pfslowtimo (arg=0x0) at /usr/src/sys/kern/uipc_domain.c:477 #10 0xc04edce6 in softclock (dummy=0x0) at /usr/src/sys/kern/kern_timeout.c:290 #11 0xc04c2088 in ithread_execute_handlers (p=0xc46c820c, ie=0xc4725c00) at /usr/src/sys/kern/kern_intr.c:684 #12 0xc04c21f7 in ithread_loop (arg=0xc46af8c0) ---Type to continue, or q to quit--- at /usr/src/sys/kern/kern_intr.c:767 #13 0xc04c0840 in fork_exit (callout=0xc04c2180 , arg=0x4, frame=0x4) at /usr/src/sys/kern/kern_fork.c:805 #14 0xc063e1ec in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:208 (kgdb) f 7 #7 0xc059291a in tcp_timer_2msl_tw (reuse=0) at atomic.h:149 149 atomic.h: No such file or directory. in atomic.h (kgdb) p *tw $1 = {tw_inpcb = 0x0, snd_nxt = 842737231, rcv_nxt = 17758516, iss = 842735507, irs = 17758065, last_win = 65534, tw_so_options = 4, tw_cred = 0x0, t_recent = 0, t_starttime = 4294952294, tw_time = 0, tw_2msl = {le_next = 0xc65ccd50, le_prev = 0xc06cf294}} (kgdb) -- Pawel From owner-freebsd-net@FreeBSD.ORG Mon Aug 21 22:01:44 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 00AB616A4DF for ; Mon, 21 Aug 2006 22:01:44 +0000 (UTC) (envelope-from mohan_srinivasan@yahoo.com) Received: from web30807.mail.mud.yahoo.com (web30807.mail.mud.yahoo.com [68.142.200.150]) by mx1.FreeBSD.org (Postfix) with SMTP id B7A8843D55 for ; Mon, 21 Aug 2006 22:01:39 +0000 (GMT) (envelope-from mohan_srinivasan@yahoo.com) Received: (qmail 82741 invoked by uid 60001); 21 Aug 2006 22:01:35 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=F2pgNL/t/0pkthOv4eROu3OF8vq16s8gY8cFIFmw/LCRulmGdbIrEpSpQAQCDlxxDbg0knXLWoAc8JqMeGgR4IbVipjzvyE8f+t6G6t1rGEnEnHvd+drnCSAjFIqFs++Nu4vqisoM6JvNroQLuzCW0+TxGkQKliGXN5qOzMRrek= ; Message-ID: <20060821220135.82739.qmail@web30807.mail.mud.yahoo.com> Received: from [207.126.239.39] by web30807.mail.mud.yahoo.com via HTTP; Mon, 21 Aug 2006 15:01:35 PDT Date: Mon, 21 Aug 2006 15:01:35 -0700 (PDT) From: Mohan Srinivasan To: Pawel Worach , net@freebsd.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: Subject: Re: [panic] page fault in tcp_timer_2msl_tw 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, 21 Aug 2006 22:01:44 -0000 I checked in a fix for this into -current a few days ago. Haven't MFC'ed it to releng 6. mohan --- Pawel Worach wrote: > On 9/22/05, Pawel Worach wrote: > > Pawel Worach wrote: > > > > > (kgdb) print *tw > > > $1 = {tw_inpcb = 0x0, snd_nxt = 438603527, rcv_nxt = 3383864561, > > > iss = 438603320, irs = 3383863898, cc_recv = 0, cc_send = 0, > > > last_win = 65534, tw_so_options = 4, tw_cred = 0x0, t_recent = 0, > > > t_starttime = 4294952294, tw_time = 0, tw_2msl = {le_next = 0xc24680a8, > > > le_prev = 0xc06a827c}} > > > > I poked a bit more and it looks like the dereference happens here in > > tcp_timer_2msl_tw(). > > > > tcp_timer.c:294 INP_LOCK(tw->tw_inpcb); > > > > INP_LOCK macro tries to reference tw->tw_inpcb->inp_mtx while > > tw->tw_inpcb is null. However I have no idea how it got to this point. > > > > Bumped into this one again on 6.1, almost a year ago since last time. > So far my conclusion is that it is hard to reproduce :) Anyone has an > idea what might be going on ? > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0xac > fault code = supervisor write, page not present > instruction pointer = 0x20:0xc059291a > stack pointer = 0x28:0xe3474bf4 > frame pointer = 0x28:0xe3474c20 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 15 (swi4: clock sio) > trap number = 12 > panic: page fault > cpuid = 2 > KDB: stack backtrace: > kdb_backtrace(c068eecd,2,c06718cd,e3474af8,a) at kdb_backtrace+0x2e > panic(c06718cd,c068fa6f,c46c8394,1,1) at panic+0x139 > trap_fatal(e3474bb4,ac,2,8,0) at trap_fatal+0x36e > trap_pfault(e3474bb4,0,ac,c0c471e0,ac) at trap_pfault+0x242 > trap(8,28,c0c40028,0,4) at trap+0x350 > calltrap() at calltrap+0x5 > --- trap 0xc, eip = 0xc059291a, esp = 0xe3474bf4, ebp = 0xe3474c20 --- > tcp_timer_2msl_tw(0,c04f462a,c06ad420,c06ad880,16) at tcp_timer_2msl_tw+0x5a > tcp_slowtimo(e3474c5c,c46c9d80,4,e3474c5c,0) at tcp_slowtimo+0x6c > pfslowtimo(0,c4826300,c06a5320,ca76356b,c46c82b4) at pfslowtimo+0x39 > softclock(0,e3474cd0,831264,61432328,c46c9d80) at softclock+0x366 > ithread_execute_handlers(c46c820c,c4725c00,0,0,0) at > ithread_execute_handlers+0x178 > ithread_loop(c46af8c0,e3474d38,0,0,0) at ithread_loop+0x77 > fork_exit(c04c2180,c46af8c0,e3474d38) at fork_exit+0x80 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0x1, eip = 0, esp = 0xe3474d6c, ebp = 0 --- > Uptime: 99d10h5m26s > Dumping 1023 MB (2 chunks) > chunk 0: 1MB (157 pages) ... ok > chunk 1: 1023MB (261851 pages) 1007 991 975 959 943 927 911 895 879 > 863 847 831 815 799 783 767 751 735 719 703 687 671 655 639 623 607 > 591 575 559 543 527 511 495 479 463 447 431 415 399 383 367 351 335 > 319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 > 15 > > #0 doadump () at pcpu.h:165 > 165 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) bt > #0 doadump () at pcpu.h:165 > #1 0xc04dde2c in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:402 > #2 0xc04de253 in panic (fmt=0xc06718cd "%s") > at /usr/src/sys/kern/kern_shutdown.c:558 > #3 0xc065481e in trap_fatal (frame=0xe3474bb4, eva=0) > at /usr/src/sys/i386/i386/trap.c:836 > #4 0xc0654482 in trap_pfault (frame=0xe3474bb4, usermode=0, eva=172) > at /usr/src/sys/i386/i386/trap.c:744 > #5 0xc0653ff0 in trap (frame= > {tf_fs = 8, tf_es = 40, tf_ds = -1060896728, tf_edi = 0, tf_esi > = 4, tf_ebp = -481866720, tf_isp = -481866784, tf_ebx = -966999536, > tf_edx = -1060867608, tf_ecx = -999514752, tf_eax = 4, tf_trapno = 12, > tf_err = 2, tf_eip = -1067898598, tf_cs = 32, tf_eflags = 66195, > tf_esp = -966999536, tf_ss = 0}) > at /usr/src/sys/i386/i386/trap.c:434 > #6 0xc063e18a in calltrap () at /usr/src/sys/i386/i386/exception.s:139 > #7 0xc059291a in tcp_timer_2msl_tw (reuse=0) at atomic.h:149 > #8 0xc05922ac in tcp_slowtimo () at /usr/src/sys/netinet/tcp_timer.c:116 > #9 0xc0522879 in pfslowtimo (arg=0x0) at /usr/src/sys/kern/uipc_domain.c:477 > #10 0xc04edce6 in softclock (dummy=0x0) at /usr/src/sys/kern/kern_timeout.c:290 > #11 0xc04c2088 in ithread_execute_handlers (p=0xc46c820c, ie=0xc4725c00) > at /usr/src/sys/kern/kern_intr.c:684 > #12 0xc04c21f7 in ithread_loop (arg=0xc46af8c0) > ---Type to continue, or q to quit--- > at /usr/src/sys/kern/kern_intr.c:767 > #13 0xc04c0840 in fork_exit (callout=0xc04c2180 , arg=0x4, > frame=0x4) at /usr/src/sys/kern/kern_fork.c:805 > #14 0xc063e1ec in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:208 > (kgdb) f 7 > #7 0xc059291a in tcp_timer_2msl_tw (reuse=0) at atomic.h:149 > 149 atomic.h: No such file or directory. > in atomic.h > (kgdb) p *tw > $1 = {tw_inpcb = 0x0, snd_nxt = 842737231, rcv_nxt = 17758516, > iss = 842735507, irs = 17758065, last_win = 65534, tw_so_options = 4, > tw_cred = 0x0, t_recent = 0, t_starttime = 4294952294, tw_time = 0, > tw_2msl = {le_next = 0xc65ccd50, le_prev = 0xc06cf294}} > (kgdb) > > -- > Pawel > _______________________________________________ > 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 Mon Aug 21 23:08:46 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A6B3B16A4DE for ; Mon, 21 Aug 2006 23:08:46 +0000 (UTC) (envelope-from patl+freebsd@volant.org) Received: from smtp.volant.org (gate.volant.org [207.111.218.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2159043D49 for ; Mon, 21 Aug 2006 23:08:41 +0000 (GMT) (envelope-from patl+freebsd@volant.org) Received: from adsl-065-081-071-131.sip.gnv.bellsouth.net ([65.81.71.131] helo=[192.168.1.121]) by smtp.volant.org with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34 (FreeBSD)) id 1GFIv4-0004oq-Qz; Mon, 21 Aug 2006 16:12:04 -0700 Date: Mon, 21 Aug 2006 16:06:08 -0400 From: Pat Lashley To: Fredrik Lindberg Message-ID: <9C04919EE684029A410DE208@garrett.local> In-Reply-To: <44EA1926.2000501@shapeshifter.se> References: <44E9F991.7020309@shapeshifter.se> <44EA1926.2000501@shapeshifter.se> X-Mailer: Mulberry/4.0.0 (Mac OS X) MIME-Version: 1.0 X-Scan-Signature: dbc2d31c1a3da52922e7a4293aa998cd24823ecb X-Spam-User: nobody X-Spam-Score: -4.1 (----) X-Spam-Score-Int: -40 X-Spam-Report: This mail has matched the spam-filter tests listed below. See http://spamassassin.org/tag/ for details about the specific tests reported. In general, the higher the number of total points, the more likely that it actually is spam. (The 'required' number of points listed below is the arbitrary number above which the message is normally considered spam.) Content analysis details: (-4.1 points total, 5.0 required) 0.1 HTML_MESSAGE BODY: HTML included in message 0.1 HTML_FONTCOLOR_RED BODY: HTML font color is red -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.4 DATE_IN_PAST_03_06 Date: is 3 to 6 hours before Received: date 0.2 AWL AWL: Auto-whitelist adjustment Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: Zeroconfig and Multicast DNS 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, 21 Aug 2006 23:08:46 -0000 > > Actually, that is IPv4 Link Local Addressing. Zeroconfig includes that, > > Multicast DNS, Service Discovery and anything else that removes the need > > for manual configuration. > > Yeah, I actually know that. It's just that I've developed a bad habit of > calling it zeroconfig in the absence of a short name, calling it > "ipv4 link local addressing" every time tends to get a bit tedious. > But I should not have done that in my previous mail, my apologies. After a quick look at your website, I figured you were probably aware of the correct usage; but thought that it might be a good idea to clarify the point for others on the list who might be new to the idea. > > I'm very glad to hear that somebody is working on IPv4 Link Local for > > FreeBSD. > > > >> Multicast DNS is DNS without a server, you can think of it as mixing > >> ... > > > > Doesn't the net/mDNSResponder port handle both mDNS and (m)DNS-based > > service discovery? Is it missing some functionality that can't be easily > > handled by a wrapper? (E.g. An nss_mdns that uses their libdns_sd.so) > > > > I didn't know there was a port of Apples daemon and I'm sure it > works just fine. The only thing that might be an issue is licensing > terms, at least in embedded solutions. My code is under a BSD license. Actually, the Apple license looks pretty reasonable; even for embedded applications. > I'll continue to hack on my responder anyway, as it's not that > far from completion. Since sending that email, I also discovered that there's a net/gdns port for the GNU version. But it appears to be under the GPL; which would be more of an issue. I just thought that it might be easier to work with one of these established projects. > The service discovery part is just a set of records in the responder > which it responds to, a service discovery client/agent is needed to > find announced records. The Apple way seems to assume that the individual applications will be linked with the service discovery library. I'm not sure that they even provide a method for the end-user to browse all available services. There is a postcard-ware third-party app called Browsejour from bleepsoft; but I'm sure that it's GUI is OS X specific. A browsing utility would certainly be useful; but if I were starting such a project, I'd write it to use one of the existing libraries from the ports. (Ideally choosing which at build time.) Of course, you aren't just starting your project, you're fairly well along; so I can understand your reluctance to switch. Is your library API fairly close to the one in mDNSResponder or gmdns? If so, it should be fairly easy to make your apps work with whichever library is installed. (I'm just thinking ahead to the point where projects like Apache, Firefox, and various GNOME apps have added service announcement/discovery and sysadmins are asking themselves why they need three different mDNS libraries installed at once...) Also, you mention the discovery client/agent; but not the advertisement. I'd really like to see an easy way to advertise services without having to modify the daemons to announce themselves. I'm particularly thinking of long-running daemons for services like http, ssh, ftp, etc.; where the service is generally made available as part of the boot sequence. It would really be great if the service advertisement could be done as a one-line addition to their rc scripts. (Something like: '[ -x /path/to/announcer ] && announce service' would be safe even if the mDNS stuff isn't installed. Actually, I suppose you'd also want a line to revoke the annoouncement in the 'stop' section. ) -Pat From owner-freebsd-net@FreeBSD.ORG Mon Aug 21 23:21:57 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BB62D16A4DE for ; Mon, 21 Aug 2006 23:21:57 +0000 (UTC) (envelope-from redchin@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.239]) by mx1.FreeBSD.org (Postfix) with ESMTP id 706E343D62 for ; Mon, 21 Aug 2006 23:21:40 +0000 (GMT) (envelope-from redchin@gmail.com) Received: by wx-out-0506.google.com with SMTP id i27so1719699wxd for ; Mon, 21 Aug 2006 16:21:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=QTXtGwpUQsoH0zsaKahVz/N2yjJkuQn9Y2gPlfkeq7rxHsggvWAcY8oIpgXOXYVJygI7oaqHe3ngnIFtepejtVG1rUAV0xUuzXUKcVF4RT36gl4FUFiFC2zg27fcpBEZRDBjTbAWodDhavaZEBY0sLiIp0Eixb4v5p2qvvBEbq0= Received: by 10.65.119.14 with SMTP id w14mr7566996qbm; Mon, 21 Aug 2006 16:21:39 -0700 (PDT) Received: by 10.64.114.3 with HTTP; Mon, 21 Aug 2006 16:21:39 -0700 (PDT) Message-ID: <1d3ed48c0608211621w3f15c31erb5e86c4e40edb6fe@mail.gmail.com> Date: Mon, 21 Aug 2006 16:21:39 -0700 From: "Kevin Downey" To: "Pat Lashley" In-Reply-To: <9C04919EE684029A410DE208@garrett.local> MIME-Version: 1.0 References: <44E9F991.7020309@shapeshifter.se> <44EA1926.2000501@shapeshifter.se> <9C04919EE684029A410DE208@garrett.local> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, Fredrik Lindberg Subject: Re: Zeroconfig and Multicast DNS 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, 21 Aug 2006 23:21:57 -0000 On 8/21/06, Pat Lashley wrote: > > > > Actually, that is IPv4 Link Local Addressing. Zeroconfig includes > that, > > > Multicast DNS, Service Discovery and anything else that removes the > need > > > for manual configuration. > > > > Yeah, I actually know that. It's just that I've developed a bad habit of > > calling it zeroconfig in the absence of a short name, calling it > > "ipv4 link local addressing" every time tends to get a bit tedious. > > But I should not have done that in my previous mail, my apologies. > > After a quick look at your website, I figured you were probably aware of > the > correct usage; but thought that it might be a good idea to clarify the > point > for others on the list who might be new to the idea. > > > > > I'm very glad to hear that somebody is working on IPv4 Link Local for > > > FreeBSD. > > > > > >> Multicast DNS is DNS without a server, you can think of it as mixing > > >> ... > > > > > > Doesn't the net/mDNSResponder port handle both mDNS and (m)DNS-based > > > service discovery? Is it missing some functionality that can't be > easily > > > handled by a wrapper? (E.g. An nss_mdns that uses their libdns_sd.so) > > > > > > > I didn't know there was a port of Apples daemon and I'm sure it > > works just fine. The only thing that might be an issue is licensing > > terms, at least in embedded solutions. My code is under a BSD license. > > Actually, the Apple license looks pretty reasonable; even for embedded > applications. > > > I'll continue to hack on my responder anyway, as it's not that > > far from completion. > > Since sending that email, I also discovered that there's a net/gdns port > for > the GNU version. But it appears to be under the GPL; which would be more > of an > issue. > > I just thought that it might be easier to work with one of these > established > projects. > > > The service discovery part is just a set of records in the responder > > which it responds to, a service discovery client/agent is needed to > > find announced records. > > The Apple way seems to assume that the individual applications will be > linked > with the service discovery library. I'm not sure that they even provide a > method for the end-user to browse all available services. There is a > postcard-ware third-party app called Browsejour from bleepsoft; but I'm > sure > that it's GUI is OS X specific. A browsing utility would certainly be > useful; > but if I were starting such a project, I'd write it to use one of the > existing > libraries from the ports. (Ideally choosing which at build time.) Of > course, > you aren't just starting your project, you're fairly well along; so I can > understand your reluctance to switch. > > Is your library API fairly close to the one in mDNSResponder or gmdns? If > so, > it should be fairly easy to make your apps work with whichever library is > installed. (I'm just thinking ahead to the point where projects like > Apache, > Firefox, and various GNOME apps have added service announcement/discovery > and > sysadmins are asking themselves why they need three different mDNS > libraries > installed at once...) > > Also, you mention the discovery client/agent; but not the advertisement. > I'd > really like to see an easy way to advertise services without having to > modify > the daemons to announce themselves. I'm particularly thinking of > long-running > daemons for services like http, ssh, ftp, etc.; where the service is > generally > made available as part of the boot sequence. It would really be great if > the > service advertisement could be done as a one-line addition to their rc > scripts. > (Something like: '[ -x /path/to/announcer ] && announce service' would be > safe > even if the mDNS stuff isn't installed. Actually, I suppose you'd also > want a > line to revoke the annoouncement in the 'stop' section. ) > > > > -Pat > _______________________________________________ > 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" > avahi provides a method for anouncing services for daemons that are not mdns aware. It is also a gnome dep. and is in ports. I would really love to see a nsswitch module for resolving mdns names since that is all that apears to be missing. -- luctor et emergo From owner-freebsd-net@FreeBSD.ORG Tue Aug 22 02:40:13 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 318D916A4DE for ; Tue, 22 Aug 2006 02:40:13 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1F77E43D49 for ; Tue, 22 Aug 2006 02:40:12 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: by py-out-1112.google.com with SMTP id o67so2652792pye for ; Mon, 21 Aug 2006 19:40:11 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=j2xI6IT+Qr7v1Pv5KLAoe7xWbE4aILq4JQjduJ3tp9q9GHnnblai51Dep6Z+fBL9MP/LDX7RGGoha1qfdUnSnOvbUuHw2foLVUOykcKqSo+0K+2ipFsw/8QpxVix2kC2kjLHiFyBH9CXgxzwoHNSAd7hHCzQVWvTV24K2WUqwEk= Received: by 10.35.114.16 with SMTP id r16mr14551083pym; Mon, 21 Aug 2006 19:40:11 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.gmail.com with ESMTP id 8sm128000nzn.2006.08.21.19.40.08; Mon, 21 Aug 2006 19:40:10 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id k7M2dnDk013753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Aug 2006 11:39:49 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id k7M2djnW013752; Tue, 22 Aug 2006 11:39:45 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Tue, 22 Aug 2006 11:39:45 +0900 From: Pyun YongHyeon To: Gleb Smirnoff , Daniel Ryslink , Jack Vogel , freebsd-net@FreeBSD.org Message-ID: <20060822023945.GB12848@cdnetworks.co.kr> References: <20060811100536.V80282@k2.vol.cz> <20060811111240.GD96644@FreeBSD.org> <20060811133531.D80282@k2.vol.cz> <20060811125825.GH96644@cell.sick.ru> <2a41acea0608110922h4bed63b1ke09f91b610819805@mail.gmail.com> <20060812094736.Q43868@k2.vol.cz> <20060812190253.GK96644@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060812190253.GK96644@cell.sick.ru> User-Agent: Mutt/1.4.2.1i Cc: Subject: Re: Problems with em interfaces on FreeBSD 6.1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2006 02:40:13 -0000 On Sat, Aug 12, 2006 at 11:02:53PM +0400, Gleb Smirnoff wrote: > On Sat, Aug 12, 2006 at 09:50:49AM +0200, Daniel Ryslink wrote: > D> Yesterday, I deployed the Intel driver version 6.1.4 compiled as a module, > D> but the problem still prevails. > D> > D> Do you have any other suggestions than debug.mpsafenet=0 ? > > The fact that debug.mpsafenet=0 fixes the problem is quite > important. I think, we will find some fix in close future. > > The only problem is to find how to reproduce the problem > _quickly_. In my setups the watchdog timeout happens few > times per day. > For a record, fix committed to HEAD(if_em.c, rev 1.133). -- Regards, Pyun YongHyeon From owner-freebsd-net@FreeBSD.ORG Tue Aug 22 08:45:50 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DABE816A4DF for ; Tue, 22 Aug 2006 08:45:50 +0000 (UTC) (envelope-from fli+freebsd-net@shapeshifter.se) Received: from mx1.h3q.net (manticore.shapeshifter.se [212.37.5.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E95E43D4C for ; Tue, 22 Aug 2006 08:45:08 +0000 (GMT) (envelope-from fli+freebsd-net@shapeshifter.se) Received: from localhost (localhost [127.0.0.1]) by mx1.h3q.net (Postfix) with ESMTP id 103EA1A751; Tue, 22 Aug 2006 10:45:06 +0200 (CEST) Received: from mx1.h3q.net ([127.0.0.1]) by localhost (mx1.h3q.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 73656-05; Tue, 22 Aug 2006 10:45:05 +0200 (CEST) Received: from [192.168.1.100] (217-208-33-252-o926.tbon.telia.com [217.208.33.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.h3q.net (Postfix) with ESMTP id 121361A72A; Tue, 22 Aug 2006 10:45:04 +0200 (CEST) Message-ID: <44EAC40E.9000904@shapeshifter.se> Date: Tue, 22 Aug 2006 10:45:02 +0200 From: Fredrik Lindberg User-Agent: Thunderbird 1.5.0.4 (X11/20060727) MIME-Version: 1.0 To: Pat Lashley References: <44E9F991.7020309@shapeshifter.se> <44EA1926.2000501@shapeshifter.se> <9C04919EE684029A410DE208@garrett.local> In-Reply-To: <9C04919EE684029A410DE208@garrett.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at h3q.net Cc: freebsd-net@freebsd.org Subject: Re: Zeroconfig and Multicast DNS 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, 22 Aug 2006 08:45:51 -0000 Pat Lashley wrote: > > Is your library API fairly close to the one in mDNSResponder or gmdns? > If so, it should be fairly easy to make your apps work with whichever > library is installed. (I'm just thinking ahead to the point where > projects like Apache, Firefox, and various GNOME apps have added service > announcement/discovery and sysadmins are asking themselves why they need > three different mDNS libraries installed at once...) > > Also, you mention the discovery client/agent; but not the advertisement. > I'd really like to see an easy way to advertise services without having > to modify the daemons to announce themselves. I'm particularly thinking > of long-running daemons for services like http, ssh, ftp, etc.; where > the service is generally made available as part of the boot sequence. It > would really be great if the service advertisement could be done as a > one-line addition to their rc scripts. (Something like: '[ -x > /path/to/announcer ] && announce service' would be safe even if the mDNS > stuff isn't installed. Actually, I suppose you'd also want a line to > revoke the annoouncement in the 'stop' section. ) > My responder does one thing (ok it's many things but anyway), it responds to queries and it makes queries. A mDNS record is always a mDNS record (shared or unique), at this point SD records are treated as any other record. Long-term records can be configured with responderd.conf, it supports dynamic variables such as $hostname, $ifaddr, $ifname etc. Once the daemon is running, you are able to communicate with it through a UNIX pipe socket. Through this socket you're able to make queries, add/remove records, dump/flush the cache etc. Of course this allows you to create records through rc scripts on start up and removal of records on shutdown. Creating a library that mimic the API of mDNSresponder or gmdns around this pipe shouldn't be a problem, but I haven't studied any of their APIs so I can't say for sure. IMHO, SD really needs a set of standardized library calls, an application that wants to publish a SD record shouldn't need to worry about which type of responder program that is running on the host. Fredrik Lindberg From owner-freebsd-net@FreeBSD.ORG Tue Aug 22 15:01:16 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A172416A4DD for ; Tue, 22 Aug 2006 15:01:16 +0000 (UTC) (envelope-from patl+freebsd@volant.org) Received: from smtp.volant.org (gate.volant.org [207.111.218.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5AB9043D66 for ; Tue, 22 Aug 2006 15:01:03 +0000 (GMT) (envelope-from patl+freebsd@volant.org) Received: from adsl-065-081-071-131.sip.gnv.bellsouth.net ([65.81.71.131] helo=[192.168.1.121]) by smtp.volant.org with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34 (FreeBSD)) id 1GFXnd-000JIs-Sf; Tue, 22 Aug 2006 08:04:24 -0700 Date: Tue, 22 Aug 2006 08:00:08 -0400 From: Pat Lashley To: Fredrik Lindberg Message-ID: <3E654CC0217F90E20FCD806E@garrett.local> In-Reply-To: <44EAC40E.9000904@shapeshifter.se> References: <44E9F991.7020309@shapeshifter.se> <44EA1926.2000501@shapeshifter.se> <9C04919EE684029A410DE208@garrett.local> <44EAC40E.9000904@shapeshifter.se> X-Mailer: Mulberry/4.0.0 (Mac OS X) MIME-Version: 1.0 X-Scan-Signature: a8d7e94cdfe9daa44db7ff9a8495f212c1006a71 X-Spam-User: nobody X-Spam-Score: -4.1 (----) X-Spam-Score-Int: -40 X-Spam-Report: This mail has matched the spam-filter tests listed below. See http://spamassassin.org/tag/ for details about the specific tests reported. In general, the higher the number of total points, the more likely that it actually is spam. (The 'required' number of points listed below is the arbitrary number above which the message is normally considered spam.) Content analysis details: (-4.1 points total, 5.0 required) 0.1 HTML_MESSAGE BODY: HTML included in message 0.1 HTML_FONTCOLOR_RED BODY: HTML font color is red -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.4 DATE_IN_PAST_03_06 Date: is 3 to 6 hours before Received: date 0.1 AWL AWL: Auto-whitelist adjustment Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: Zeroconfig and Multicast DNS 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, 22 Aug 2006 15:01:16 -0000 > My responder does one thing (ok it's many things but anyway), it > responds to queries and it makes queries. A mDNS record is always > a mDNS record (shared or unique), at this point SD records are > treated as any other record. > > Long-term records can be configured with responderd.conf, it > supports dynamic variables such as $hostname, $ifaddr, $ifname etc. As has been pointed out, avahi also allows services to be defined in a config file. That's good; but it would be better if there were also a simple utility program that could add or remove records based on command-line parameters. Then it could be invoked by the rc script to better reflect whether or not the service is actually running. (And that means only one thing to change when enabling/disabling a service.) Of course, having the daemon itself add the service record is even better; but that requires modifying the code for each daemon; and getting those modifications accepted back into the main distribution for those daemons. A simple utility script makes it easier to integrate non-mDNS-aware daemons into a zeroconf-based environment. > Once the daemon is running, you are able to communicate with it > through a UNIX pipe socket. > Through this socket you're able to make queries, add/remove records, > dump/flush the cache etc. > Of course this allows you to create records through rc scripts on > start up and removal of records on shutdown. So basically, the command would be "echo '...' >> /path/to/pipe" ? That's certainly convenient; but I doubt that it is compatible with the other mDNS implementations. A common utility name and command-line API for that would make it much more likely that it would be adopted by the bundled rc scripts, even if the mDNS code is not bundled. (There's no reason that utility couldn't be a script > Creating a library that mimic the API of mDNSresponder or gmdns > around this pipe shouldn't be a problem, but I haven't studied any > of their APIs so I can't say for sure. > > IMHO, SD really needs a set of standardized library calls, an application that > wants to publish a SD record shouldn't need to > worry about which type of responder program that is running on the host. I believe that that's the point of the libdns_sd library in the mDNSResponder port, libgmdns in the gmdns port, and one of the several libraries in the avahi port. They provide the service announcement/discovery API to be used by applications. I haven't looked at either API; so I have no idea how compatible they are. It would certainly be helpful to have a common API so that the choice of which to use could be made at application-load time. As I investigate further, it appears that avahi is the most mature, feature-rich, and widely supported and adopted mDNS implementation. The only potential drawback would be the GPL. I've also discovered that Apple are moving the iCal server, Bonjour, and launchd to the Apache 2.0 license; which should be acceptable to those who don't like the GPL. And apparently the Bonjour client libraries are already BSD licensed. Overall, I think your work on the IPv4 Link Local Addressing is much more important and useful (and more likely to be adopted) than another mDNS implementation. The LLA is the one piece that is currently missing for FreeBSD. -Pat From owner-freebsd-net@FreeBSD.ORG Tue Aug 22 19:16:08 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9793E16A4DA for ; Tue, 22 Aug 2006 19:16:08 +0000 (UTC) (envelope-from fbsd@synoptic.org) Received: from gort.synoptic.org (gort.synoptic.org [216.254.17.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 17A4443D55 for ; Tue, 22 Aug 2006 19:16:07 +0000 (GMT) (envelope-from fbsd@synoptic.org) Received: by gort.synoptic.org (Postfix, from userid 1000) id A43596352EBE; Tue, 22 Aug 2006 12:16:07 -0700 (PDT) Date: Tue, 22 Aug 2006 12:16:07 -0700 From: Xander To: freebsd-net@freebsd.org Message-ID: <20060822191607.GA27130@gort.synoptic.org> References: <20060821165401.GB804@gremlin.foo.is> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060821165401.GB804@gremlin.foo.is> User-Agent: Mutt/1.4.2.1i Cc: Baldur Gislason Subject: Re: Multicast 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, 22 Aug 2006 19:16:08 -0000 On Mon, Aug 21, 2006 at 04:54:01PM +0000, Baldur Gislason wrote: > I'm having some problems receiving multicast traffic on my FreeBSD > 6.1-STABLE workstation with VLC. I get the streams but I seem to get > plenty of packetloss on the freebsd box but on other boxes on the same > network I don't see such problems. I haven't noticed any packetloss > with unicast. Any thoughts? I've tried running a GENERIC kernel and > that makes no difference, I've also tried two different network cards. > (em and fxp) I'm afraid that I only have time for a short reply at the moment, but are you using pf? I believe I may have run into an issue where pf doesn't handle tunneled multicast routing (mrouted tunnel) very well. The issue appears to have something to do with pf not understanding on what interface the unencapsulated multicast packet arrived on (since it's re-injected into the stack by mrouted). (This was seen on 6.1-RELEASE-p3 and 6.1-STABLE as of a week ago) At any rate, if you are using pf you might try disabling it and seeing if that helps your problem. cheers -x From owner-freebsd-net@FreeBSD.ORG Tue Aug 22 19:33:29 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3C80F16A4DE for ; Tue, 22 Aug 2006 19:33:29 +0000 (UTC) (envelope-from fbsd@synoptic.org) Received: from gort.synoptic.org (gort.synoptic.org [216.254.17.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 234A743D73 for ; Tue, 22 Aug 2006 19:33:19 +0000 (GMT) (envelope-from fbsd@synoptic.org) Received: by gort.synoptic.org (Postfix, from userid 1000) id 7D4686352EBE; Tue, 22 Aug 2006 12:33:19 -0700 (PDT) Date: Tue, 22 Aug 2006 12:33:19 -0700 From: Xander To: freebsd-net@freebsd.org Message-ID: <20060822193319.GB27130@gort.synoptic.org> References: <021a01c6c322$d52bf510$4345a8c0@phobos> <20060819025613.GB11181@lor.one-eyed-alien.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060819025613.GB11181@lor.one-eyed-alien.net> User-Agent: Mutt/1.4.2.1i Subject: Re: dhclient and multiple addresses on single interface X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2006 19:33:29 -0000 On Fri, Aug 18, 2006 at 09:56:13PM -0500, Brooks Davis wrote: > > Not easily. If you could create some virtual ethernet interfaces, > bridge them to the real one and run dhclient on them I think that would > work, but I can't think of a suitable virtual interface at the moment. > I've actually played with this a little and got some enouraging results by using netgraph to create a number of virtual ethernet interfaces all linked to a netgraph bridge node linked to a physical interface. However, I ultimately ran into an issue where the global ARP table was making it difficult to actually *use* any of the other virtual interfaces. (when you resolve an ARP address on the local subnet, you remember what interface you resolved in on and tend to prefer that interface for all communications whether you want to or not). I didn't rule out the possibility that some serious firewall hackery/NATing could get around this problem. YMMV but netgraph is probably a good avenue to explore next if you haven't done so already. Oh, also I seem to remember thinking that a recent commit to the 6.1-STABLE codebase might have helped the arp difficulty I was experiencing, so it may all work better now than I did when I was playing with it. -x From owner-freebsd-net@FreeBSD.ORG Tue Aug 22 20:21:07 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 73DA716A4DA for ; Tue, 22 Aug 2006 20:21:07 +0000 (UTC) (envelope-from baldur@foo.is) Received: from gremlin.foo.is (gremlin.foo.is [194.105.250.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id E6C2B43D4C for ; Tue, 22 Aug 2006 20:21:02 +0000 (GMT) (envelope-from baldur@foo.is) Received: from 127.0.0.1 (localhost.foo.is [127.0.0.1]) by injector.foo.is (Postfix) with SMTP id 85E0EDA86B; Tue, 22 Aug 2006 20:21:01 +0000 (GMT) Received: by gremlin.foo.is (Postfix, from userid 1000) id F3109DA847; Tue, 22 Aug 2006 20:20:58 +0000 (GMT) Date: Tue, 22 Aug 2006 20:20:58 +0000 From: Baldur Gislason To: Xander Message-ID: <20060822202058.GC804@gremlin.foo.is> References: <20060821165401.GB804@gremlin.foo.is> <20060822191607.GA27130@gort.synoptic.org> In-Reply-To: <20060822191607.GA27130@gort.synoptic.org> User-Agent: Mutt/1.4.2.1i X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on gremlin.foo.is X-Spam-Level: X-Spam-Status: No, score=-5.9 required=6.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 X-Sanitizer: Foo MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Cc: freebsd-net@freebsd.org Subject: Re: Multicast 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, 22 Aug 2006 20:21:07 -0000 No, and I tried booting a GENERIC kernel also to rule out ipfw. Baldur On Tue, Aug 22, 2006 at 12:16:07PM -0700, Xander wrote: > On Mon, Aug 21, 2006 at 04:54:01PM +0000, Baldur Gislason wrote: > > > I'm having some problems receiving multicast traffic on my FreeBSD > > 6.1-STABLE workstation with VLC. I get the streams but I seem to get > > plenty of packetloss on the freebsd box but on other boxes on the same > > network I don't see such problems. I haven't noticed any packetloss > > with unicast. Any thoughts? I've tried running a GENERIC kernel and > > that makes no difference, I've also tried two different network cards. > > (em and fxp) > > I'm afraid that I only have time for a short reply at the moment, > but are you using pf? I believe I may have run into an issue where > pf doesn't handle tunneled multicast routing (mrouted tunnel) very > well. The issue appears to have something to do with pf not > understanding on what interface the unencapsulated multicast packet > arrived on (since it's re-injected into the stack by mrouted). > (This was seen on 6.1-RELEASE-p3 and 6.1-STABLE as of a week ago) > > At any rate, if you are using pf you might try disabling it and seeing > if that helps your problem. > > cheers > -x > > From owner-freebsd-net@FreeBSD.ORG Wed Aug 23 16:16:56 2006 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B47AE16A4DE; Wed, 23 Aug 2006 16:16:56 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 146D243D46; Wed, 23 Aug 2006 16:16:55 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.4/8.13.3) with ESMTP id k7NGGoW8077782 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Aug 2006 20:16:50 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.4/8.13.1/Submit) id k7NGGnG4077781; Wed, 23 Aug 2006 20:16:49 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Wed, 23 Aug 2006 20:16:49 +0400 From: Gleb Smirnoff To: David Christensen Message-ID: <20060823161649.GE76666@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline User-Agent: Mutt/1.5.6i Cc: brad@openbsd.org, oleg@FreeBSD.org, net@FreeBSD.org Subject: bge(4) one packet wedge 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, 23 Aug 2006 16:16:56 -0000 Colleagues, I've faced a problem in bge(4) when a single packet is in the RX ring, but it isn't noticed by the driver. A reception of a packet triggers interrupt and both packets are processed - an old one and the new one. To reproduce the problem you need to run netperf (from ports collection): netserver on another host (10.0.0.1) and netperf on the host, where tested bge(4) is installed - 10.0.0.2. No traffic except netperf's should flow through this NIC, or the problem won't be reproduced! So, I run netperf client and simultaneously tcpdump on the another host. After few seconds there is a wedge. The last packet seen on 10.0.0.1 is the packet sent by 10.0.0.1 to 10.0.0.2. However it isn't seen on 10.0.0.2. Ok, let's look at the receive ring: (kgdb) p $sc->bge_rx_saved_considx $14 = 51 (kgdb) p $sc->bge_ldata.bge_status_block->bge_idx[0].bge_rx_prod_idx $15 = 51 Looks like there is nothing to process. However, if I run 'ping -c 1 10.0.0.2' I will get an interrupt and read two packets: first the old packet, and then recently sent ping. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Wed Aug 23 17:30:41 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1255616A4DA for ; Wed, 23 Aug 2006 17:30:41 +0000 (UTC) (envelope-from fli+freebsd-net@shapeshifter.se) Received: from mx1.h3q.net (manticore.shapeshifter.se [212.37.5.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8FC9443D45 for ; Wed, 23 Aug 2006 17:30:38 +0000 (GMT) (envelope-from fli+freebsd-net@shapeshifter.se) Received: from localhost (localhost [127.0.0.1]) by mx1.h3q.net (Postfix) with ESMTP id 0B8F21A78D; Wed, 23 Aug 2006 19:30:36 +0200 (CEST) Received: from mx1.h3q.net ([127.0.0.1]) by localhost (mx1.h3q.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09199-08; Wed, 23 Aug 2006 19:30:35 +0200 (CEST) Received: from [192.168.1.100] (217-208-33-252-o926.tbon.telia.com [217.208.33.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.h3q.net (Postfix) with ESMTP id 1FE7B1A751; Wed, 23 Aug 2006 19:30:34 +0200 (CEST) Message-ID: <44EC90B7.6090908@shapeshifter.se> Date: Wed, 23 Aug 2006 19:30:31 +0200 From: Fredrik Lindberg User-Agent: Thunderbird 1.5.0.4 (X11/20060727) MIME-Version: 1.0 To: Pat Lashley References: <44E9F991.7020309@shapeshifter.se> <44EA1926.2000501@shapeshifter.se> <9C04919EE684029A410DE208@garrett.local> <44EAC40E.9000904@shapeshifter.se> <3E654CC0217F90E20FCD806E@garrett.local> In-Reply-To: <3E654CC0217F90E20FCD806E@garrett.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at h3q.net Cc: freebsd-net@freebsd.org Subject: Re: Zeroconfig and Multicast DNS 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, 23 Aug 2006 17:30:41 -0000 Pat Lashley wrote: > > As I investigate further, it appears that avahi is the most mature, > feature-rich, and widely supported and adopted mDNS implementation. The > only potential drawback would be the GPL. > > I've also discovered that Apple are moving the iCal server, Bonjour, and > launchd to the Apache 2.0 license; which should be acceptable to those > who don't like the GPL. And apparently the Bonjour client libraries are > already BSD licensed. > > The thing is that I would like to see mDNS in base (and the other zeroconfig utilities). Avahi might be the most mature at the moment, but as it is GPL it's not an option when there are other responders available. mDNSResponder-108 appears to still be under APSL 2, I don't know if that license is acceptable for base utilities, if it is, it might be a viable alternative. However that doesn't have a chance of happening unless a committer finds it interesting. > > Overall, I think your work on the IPv4 Link Local Addressing is much > more important and useful (and more likely to be adopted) than another > mDNS implementation. The LLA is the one piece that is currently missing > for FreeBSD. > Well, my LLA implementation (I renamed it to llacd, link local address configuration daemon) is already quite mature. It has been running on a machine here for over a month without problems. Fredrik Lindberg From owner-freebsd-net@FreeBSD.ORG Wed Aug 23 17:45:14 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 806E816A4DD for ; Wed, 23 Aug 2006 17:45:14 +0000 (UTC) (envelope-from bmw@borderware.com) Received: from mail.borderware.com (mail.borderware.com [207.236.65.231]) by mx1.FreeBSD.org (Postfix) with ESMTP id 06BC143D45 for ; Wed, 23 Aug 2006 17:45:13 +0000 (GMT) (envelope-from bmw@borderware.com) Message-ID: <44EC9426.7040002@borderware.com> Date: Wed, 23 Aug 2006 13:45:10 -0400 From: Bruce Walker Organization: BorderWare Technologies Inc. User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719) MIME-Version: 1.0 To: Fredrik Lindberg References: <44E9F991.7020309@shapeshifter.se> <44EA1926.2000501@shapeshifter.se> <9C04919EE684029A410DE208@garrett.local> <44EAC40E.9000904@shapeshifter.se> <3E654CC0217F90E20FCD806E@garrett.local> <44EC90B7.6090908@shapeshifter.se> In-Reply-To: <44EC90B7.6090908@shapeshifter.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Zeroconfig and Multicast DNS 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, 23 Aug 2006 17:45:14 -0000 Fredrik Lindberg wrote: > mDNSResponder-108 appears to still be under APSL 2, I don't > know if that license is acceptable for base utilities, if it is, it > might be a viable alternative. It should be under the Apache 2.0 license now. Here's the announcement from the bonjour-dev list ... -------- Original Message -------- Subject: Fwd: Apple Opens Up: Bonjour now under Apache license Date: Mon, 7 Aug 2006 16:43:16 -0700 From: Ernest Prabhakar To: bonjour-dev@lists.apple.com References: <426EEC4B-6306-4EAC-A70B-A10BE531CB9E@apple.com> Hi all, As most of you know, Apple believes in the power of Open Source as a great way to enable adoption of standards-based technologies. To make Bonjour even more attractive to various solution providers, we are pleased to announce that those portions of Bonjour previously under the Apple Public Source License** are now available under the widely-used Apache License, Version 2.0*. The relicensed sources are currently available in the Bonjour CVS; additional information is available in the new Mac OS Forge community hosting site: We hope this inspires you to use Bonjour as part of even more innovative products. Sincerely, Ernest Prabhakar Open Source Product Manager, Apple Begin forwarded message: > Subject: Apple Opens Up: Kernel, Mac OS Forge, iCal Server, > Bonjour, Launchd > > Hi all, > > In conjunction with this week's Developer Conference, we have four > great pieces of news for Open Source developers: > > A. Intel Kernel Sources > > As of today, we are posting buildable kernel sources for Intel- > based Macs alongside the usual PowerPC (and other Intel) sources, > starting with Mac OS X 10.4.7. We regret the delay in readying the > new kernel for release, and thank you for your patience. > > http://www.opensource.apple.com/darwinsource/tarballs/apsl/ > xnu-792.10.96.tar.gz > > B. New "Mac OS Forge" for Community Projects > > Mac OS Forge, a new community site hosted by Apple, is being > created to support WebKit and other open source projects focused on > Mac OS X, especially those looking to transition from OpenDarwin.org. > > > > C. New Open Source Calendaring Server > > In order to encourage community participation, source code to the > new iCal Server in Leopard Server is now available on Mac OS Forge > under the Apache License.* > > > > D. Apache-Licensed Bonjour and Launchd sources > > To further enable and encourage cross-platform adoption, the APSL** > sources for Bonjour service discovery and Launchd process > management are being re-released under the Apache License and > hosted on Mac OS Forge: > > > > > Apple is more excited than ever about the power of Open Source > development to create value for our (and your) products and > customers. I'll be offline much of this week due to WWDC, but I > look forward to working with all of you as we move forward to Leopard. > > Sincerely, > Ernest Prabhakar > Open Source Product Manager, Apple > WWDC 2006, Aug 7-11, San Francisco > > > * Apache License, Version 2.0 > > > ** Apple Public Source License 2.0 > From owner-freebsd-net@FreeBSD.ORG Wed Aug 23 18:07:21 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EF0B516A4E0 for ; Wed, 23 Aug 2006 18:07:21 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from sccmmhc91.asp.att.net (sccmmhc91.asp.att.net [204.127.203.211]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E43143D4C for ; Wed, 23 Aug 2006 18:07:17 +0000 (GMT) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net ([12.207.12.9]) by sccmmhc91.asp.att.net (sccmmhc91) with ESMTP id <20060823180657m910086oq0e>; Wed, 23 Aug 2006 18:07:11 +0000 Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.13.6/8.13.6) with ESMTP id k7NI6kbN026680; Wed, 23 Aug 2006 13:06:46 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.13.6/8.13.6/Submit) id k7NI6Sxg026679; Wed, 23 Aug 2006 13:06:28 -0500 (CDT) (envelope-from brooks) Date: Wed, 23 Aug 2006 13:06:28 -0500 From: Brooks Davis To: Bruce Walker Message-ID: <20060823180628.GA26635@lor.one-eyed-alien.net> References: <44E9F991.7020309@shapeshifter.se> <44EA1926.2000501@shapeshifter.se> <9C04919EE684029A410DE208@garrett.local> <44EAC40E.9000904@shapeshifter.se> <3E654CC0217F90E20FCD806E@garrett.local> <44EC90B7.6090908@shapeshifter.se> <44EC9426.7040002@borderware.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/9DWx/yDrRhgMJTb" Content-Disposition: inline In-Reply-To: <44EC9426.7040002@borderware.com> User-Agent: Mutt/1.5.11 Cc: freebsd-net@freebsd.org, Fredrik Lindberg Subject: Re: Zeroconfig and Multicast DNS 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, 23 Aug 2006 18:07:22 -0000 --/9DWx/yDrRhgMJTb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 23, 2006 at 01:45:10PM -0400, Bruce Walker wrote: > Fredrik Lindberg wrote: > >mDNSResponder-108 appears to still be under APSL 2, I don't > >know if that license is acceptable for base utilities, if it is, it > >might be a viable alternative. >=20 > It should be under the Apache 2.0 license now. I think we're mostly OK with the Apache License, but I don't think core has actually ruled on the subject. We can import APSL code under certain circumstances, but we generally treat it as GPL'd code and prefer not to. -- Brooks > Here's the announcement from the bonjour-dev list ... >=20 >=20 > -------- Original Message -------- > Subject: Fwd: Apple Opens Up: Bonjour now under Apache license > Date: Mon, 7 Aug 2006 16:43:16 -0700 > From: Ernest Prabhakar > To: bonjour-dev@lists.apple.com > References: <426EEC4B-6306-4EAC-A70B-A10BE531CB9E@apple.com> >=20 >=20 >=20 > Hi all, >=20 > As most of you know, Apple believes in the power of Open Source as a =20 > great way to enable adoption of standards-based technologies. To =20 > make Bonjour even more attractive to various solution providers, we =20 > are pleased to announce that those portions of Bonjour previously =20 > under the Apple Public Source License** are now available under the =20 > widely-used Apache License, Version 2.0*. The relicensed sources are =20 > currently available in the Bonjour CVS; additional information is =20 > available in the new Mac OS Forge community hosting site: >=20 > >=20 > We hope this inspires you to use Bonjour as part of even more =20 > innovative products. >=20 > Sincerely, > Ernest Prabhakar > Open Source Product Manager, Apple >=20 > Begin forwarded message: > >Subject: Apple Opens Up: Kernel, Mac OS Forge, iCal Server, =20 > >Bonjour, Launchd > > > >Hi all, > > > >In conjunction with this week's Developer Conference, we have four =20 > >great pieces of news for Open Source developers: > > > >A. Intel Kernel Sources > > > >As of today, we are posting buildable kernel sources for Intel-=20 > >based Macs alongside the usual PowerPC (and other Intel) sources, =20 > >starting with Mac OS X 10.4.7. We regret the delay in readying the =20 > >new kernel for release, and thank you for your patience. > > > >http://www.opensource.apple.com/darwinsource/tarballs/apsl/=20 > >xnu-792.10.96.tar.gz > > > >B. New "Mac OS Forge" for Community Projects > > > >Mac OS Forge, a new community site hosted by Apple, is being =20 > >created to support WebKit and other open source projects focused on =20 > >Mac OS X, especially those looking to transition from OpenDarwin.org. > > > > > > > >C. New Open Source Calendaring Server > > > >In order to encourage community participation, source code to the =20 > >new iCal Server in Leopard Server is now available on Mac OS Forge =20 > >under the Apache License.* > > > > > > > >D. Apache-Licensed Bonjour and Launchd sources > > > >To further enable and encourage cross-platform adoption, the APSL** =20 > >sources for Bonjour service discovery and Launchd process =20 > >management are being re-released under the Apache License and =20 > >hosted on Mac OS Forge: > > > > > > > > > >Apple is more excited than ever about the power of Open Source =20 > >development to create value for our (and your) products and =20 > >customers. I'll be offline much of this week due to WWDC, but I =20 > >look forward to working with all of you as we move forward to Leopard. > > > >Sincerely, > >Ernest Prabhakar > >Open Source Product Manager, Apple > >WWDC 2006, Aug 7-11, San Francisco > > > > > >* Apache License, Version 2.0 > > > > > >** Apple Public Source License 2.0 > > >=20 >=20 > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >=20 --/9DWx/yDrRhgMJTb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFE7JkjXY6L6fI4GtQRAh4kAJ9V16Zc6ksAWgYvujWTGMaGVBm/fACg3Blm iLBGmvJhQ1x+GR6WkU5XJ0I= =RiTK -----END PGP SIGNATURE----- --/9DWx/yDrRhgMJTb-- From owner-freebsd-net@FreeBSD.ORG Wed Aug 23 18:19:20 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2ED8316A4DD for ; Wed, 23 Aug 2006 18:19:20 +0000 (UTC) (envelope-from fli+freebsd-net@shapeshifter.se) Received: from mx1.h3q.net (manticore.shapeshifter.se [212.37.5.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2A87D43D73 for ; Wed, 23 Aug 2006 18:19:13 +0000 (GMT) (envelope-from fli+freebsd-net@shapeshifter.se) Received: from localhost (localhost [127.0.0.1]) by mx1.h3q.net (Postfix) with ESMTP id C15E01A78D; Wed, 23 Aug 2006 20:19:12 +0200 (CEST) Received: from mx1.h3q.net ([127.0.0.1]) by localhost (mx1.h3q.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13379-04; Wed, 23 Aug 2006 20:19:10 +0200 (CEST) Received: from [192.168.1.100] (217-208-33-252-o926.tbon.telia.com [217.208.33.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.h3q.net (Postfix) with ESMTP id 141D51A751; Wed, 23 Aug 2006 20:19:10 +0200 (CEST) Message-ID: <44EC9C1B.5000706@shapeshifter.se> Date: Wed, 23 Aug 2006 20:19:07 +0200 From: Fredrik Lindberg User-Agent: Thunderbird 1.5.0.4 (X11/20060727) MIME-Version: 1.0 To: Bruce Walker References: <44E9F991.7020309@shapeshifter.se> <44EA1926.2000501@shapeshifter.se> <9C04919EE684029A410DE208@garrett.local> <44EAC40E.9000904@shapeshifter.se> <3E654CC0217F90E20FCD806E@garrett.local> <44EC90B7.6090908@shapeshifter.se> <44EC9426.7040002@borderware.com> In-Reply-To: <44EC9426.7040002@borderware.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at h3q.net Cc: freebsd-net@freebsd.org Subject: Re: Zeroconfig and Multicast DNS 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, 23 Aug 2006 18:19:20 -0000 Bruce Walker wrote: > Fredrik Lindberg wrote: >> mDNSResponder-108 appears to still be under APSL 2, I don't >> know if that license is acceptable for base utilities, if it is, it >> might be a viable alternative. > > It should be under the Apache 2.0 license now. > Yes, you are correct. I just grabbed the latest version from their cvs and its indeed under the Apache 2.0 license now. Fredrik Lindberg From owner-freebsd-net@FreeBSD.ORG Wed Aug 23 18:26:54 2006 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3A77216A4DA; Wed, 23 Aug 2006 18:26:54 +0000 (UTC) (envelope-from oleg@lath.rinet.ru) Received: from lath.rinet.ru (lath.rinet.ru [195.54.192.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id 920AD43D46; Wed, 23 Aug 2006 18:26:53 +0000 (GMT) (envelope-from oleg@lath.rinet.ru) Received: from lath.rinet.ru (localhost [127.0.0.1]) by lath.rinet.ru (8.13.6/8.13.6) with ESMTP id k7NIQn8P023760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Aug 2006 22:26:49 +0400 (MSD) (envelope-from oleg@lath.rinet.ru) Received: (from oleg@localhost) by lath.rinet.ru (8.13.6/8.13.6/Submit) id k7NIQn6Q023759; Wed, 23 Aug 2006 22:26:49 +0400 (MSD) (envelope-from oleg) Date: Wed, 23 Aug 2006 22:26:48 +0400 From: Oleg Bulyzhin To: Gleb Smirnoff Message-ID: <20060823182648.GA22888@lath.rinet.ru> References: <20060823161649.GE76666@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060823161649.GE76666@cell.sick.ru> User-Agent: Mutt/1.5.11 Cc: brad@openbsd.org, David Christensen , net@FreeBSD.org Subject: Re: bge(4) one packet wedge 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, 23 Aug 2006 18:26:54 -0000 On Wed, Aug 23, 2006 at 08:16:49PM +0400, Gleb Smirnoff wrote: > Colleagues, > > I've faced a problem in bge(4) when a single packet is in the RX > ring, but it isn't noticed by the driver. A reception of a packet > triggers interrupt and both packets are processed - an old one > and the new one. > > To reproduce the problem you need to run netperf (from ports > collection): netserver on another host (10.0.0.1) and netperf on > the host, where tested bge(4) is installed - 10.0.0.2. No traffic > except netperf's should flow through this NIC, or the problem won't > be reproduced! > > So, I run netperf client and simultaneously tcpdump on the > another host. After few seconds there is a wedge. The last packet > seen on 10.0.0.1 is the packet sent by 10.0.0.1 to 10.0.0.2. However > it isn't seen on 10.0.0.2. > > Ok, let's look at the receive ring: > > (kgdb) p $sc->bge_rx_saved_considx > $14 = 51 > (kgdb) p $sc->bge_ldata.bge_status_block->bge_idx[0].bge_rx_prod_idx > $15 = 51 > > Looks like there is nothing to process. > > However, if I run 'ping -c 1 10.0.0.2' I will get an interrupt and read > two packets: first the old packet, and then recently sent ping. > > -- > Totus tuus, Glebius. > GLEBIUS-RIPN GLEB-RIPE What happens if you trigger other interrupt (like unplug/plug cable)? Will you get that packet? -- Oleg. From owner-freebsd-net@FreeBSD.ORG Wed Aug 23 18:46:11 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E9ACC16A4DA; Wed, 23 Aug 2006 18:46:11 +0000 (UTC) (envelope-from prvs=julian=383e896f4@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id ACB5A43D55; Wed, 23 Aug 2006 18:46:09 +0000 (GMT) (envelope-from prvs=julian=383e896f4@elischer.org) Received: from unknown (HELO [10.251.18.229]) ([10.251.18.229]) by a50.ironport.com with ESMTP; 23 Aug 2006 11:46:08 -0700 Message-ID: <44ECA26F.2080204@elischer.org> Date: Wed, 23 Aug 2006 11:46:07 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gleb Smirnoff References: <20060823161649.GE76666@cell.sick.ru> In-Reply-To: <20060823161649.GE76666@cell.sick.ru> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: brad@openbsd.org, David Christensen , oleg@freebsd.org, net@freebsd.org Subject: Re: bge(4) one packet wedge 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, 23 Aug 2006 18:46:12 -0000 Gleb Smirnoff wrote: > Colleagues, > > I've faced a problem in bge(4) when a single packet is in the RX >ring, but it isn't noticed by the driver. A reception of a packet >triggers interrupt and both packets are processed - an old one >and the new one. > > To reproduce the problem you need to run netperf (from ports >collection): netserver on another host (10.0.0.1) and netperf on >the host, where tested bge(4) is installed - 10.0.0.2. No traffic >except netperf's should flow through this NIC, or the problem won't >be reproduced! > > So, I run netperf client and simultaneously tcpdump on the >another host. After few seconds there is a wedge. The last packet >seen on 10.0.0.1 is the packet sent by 10.0.0.1 to 10.0.0.2. However >it isn't seen on 10.0.0.2. > >Ok, let's look at the receive ring: > >(kgdb) p $sc->bge_rx_saved_considx >$14 = 51 >(kgdb) p $sc->bge_ldata.bge_status_block->bge_idx[0].bge_rx_prod_idx >$15 = 51 > >Looks like there is nothing to process. > >However, if I run 'ping -c 1 10.0.0.2' I will get an interrupt and read >two packets: first the old packet, and then recently > Is there any IPMI set up on the machine? is it possible that some extra circuitry involved with ipmi is holding the packet? >sent ping. > > > From owner-freebsd-net@FreeBSD.ORG Wed Aug 23 19:31:27 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F355D16A4DD; Wed, 23 Aug 2006 19:31:26 +0000 (UTC) (envelope-from oleg@lath.rinet.ru) Received: from lath.rinet.ru (lath.rinet.ru [195.54.192.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C82D43D4C; Wed, 23 Aug 2006 19:31:25 +0000 (GMT) (envelope-from oleg@lath.rinet.ru) Received: from lath.rinet.ru (localhost [127.0.0.1]) by lath.rinet.ru (8.13.6/8.13.6) with ESMTP id k7NJVMF4024444 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Aug 2006 23:31:22 +0400 (MSD) (envelope-from oleg@lath.rinet.ru) Received: (from oleg@localhost) by lath.rinet.ru (8.13.6/8.13.6/Submit) id k7NJVLK3024443; Wed, 23 Aug 2006 23:31:21 +0400 (MSD) (envelope-from oleg) Date: Wed, 23 Aug 2006 23:31:21 +0400 From: Oleg Bulyzhin To: Gleb Smirnoff Message-ID: <20060823193121.GA24408@lath.rinet.ru> References: <20060823161649.GE76666@cell.sick.ru> <20060823182648.GA22888@lath.rinet.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060823182648.GA22888@lath.rinet.ru> User-Agent: Mutt/1.5.11 Cc: brad@openbsd.org, David Christensen , net@freebsd.org Subject: Re: bge(4) one packet wedge 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, 23 Aug 2006 19:31:27 -0000 On Wed, Aug 23, 2006 at 10:26:48PM +0400, Oleg Bulyzhin wrote: > On Wed, Aug 23, 2006 at 08:16:49PM +0400, Gleb Smirnoff wrote: > > Colleagues, > > > > I've faced a problem in bge(4) when a single packet is in the RX > > ring, but it isn't noticed by the driver. A reception of a packet > > triggers interrupt and both packets are processed - an old one > > and the new one. > > > > To reproduce the problem you need to run netperf (from ports > > collection): netserver on another host (10.0.0.1) and netperf on > > the host, where tested bge(4) is installed - 10.0.0.2. No traffic > > except netperf's should flow through this NIC, or the problem won't > > be reproduced! > > > > So, I run netperf client and simultaneously tcpdump on the > > another host. After few seconds there is a wedge. The last packet > > seen on 10.0.0.1 is the packet sent by 10.0.0.1 to 10.0.0.2. However > > it isn't seen on 10.0.0.2. > > > > Ok, let's look at the receive ring: > > > > (kgdb) p $sc->bge_rx_saved_considx > > $14 = 51 > > (kgdb) p $sc->bge_ldata.bge_status_block->bge_idx[0].bge_rx_prod_idx > > $15 = 51 > > > > Looks like there is nothing to process. > > > > However, if I run 'ping -c 1 10.0.0.2' I will get an interrupt and read > > two packets: first the old packet, and then recently sent ping. > > > > -- > > Totus tuus, Glebius. > > GLEBIUS-RIPN GLEB-RIPE > > What happens if you trigger other interrupt (like unplug/plug cable)? > Will you get that packet? > > -- > Oleg. > > _______________________________________________ > 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" Does polling(4) solve the issue? -- Oleg. From owner-freebsd-net@FreeBSD.ORG Wed Aug 23 19:48:07 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 01EDB16A4DD for ; Wed, 23 Aug 2006 19:48:07 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx24.fluidhosting.com [204.14.89.7]) by mx1.FreeBSD.org (Postfix) with SMTP id D96B743D5C for ; Wed, 23 Aug 2006 19:48:05 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 31826 invoked by uid 399); 23 Aug 2006 19:48:05 -0000 Received: from localhost (HELO ?192.168.0.3?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 23 Aug 2006 19:48:05 -0000 Message-ID: <44ECB0F2.9040300@FreeBSD.org> Date: Wed, 23 Aug 2006 12:48:02 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 1.5.0.5 (X11/20060729) MIME-Version: 1.0 To: Fredrik Lindberg References: <44E9F991.7020309@shapeshifter.se> <44EA1926.2000501@shapeshifter.se> <9C04919EE684029A410DE208@garrett.local> <44EAC40E.9000904@shapeshifter.se> <3E654CC0217F90E20FCD806E@garrett.local> <44EC90B7.6090908@shapeshifter.se> In-Reply-To: <44EC90B7.6090908@shapeshifter.se> X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Pat Lashley Subject: Re: Zeroconfig and Multicast DNS 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, 23 Aug 2006 19:48:07 -0000 Fredrik Lindberg wrote: > The thing is that I would like to see mDNS in base (and the other > zeroconfig utilities). ... > However that doesn't have a chance of happening unless a committer finds > it interesting. I find it very interesting. :) One of my side projects at the moment is to come further up to speed on the subject of multicast DNS in general, so I'm following this discussion with a great deal of interest. I'd really like to see FreeBSD take a lead in this area, since the more research I do the more I am convinced that this, or something very much like it is the future of end-user network provisioning. If no one else steps forward, I will be glad to lead the charge to get an implementation of this committed. Before I do though, we'll need to get some basic questions answered (some of which have already been discussed here). 1. What are the other *BSDs doing in this area? 2. What are the linux flavors doing? 3. What is the minimal set of features we should support? (I think this list starts with LLA, but that's just a gut feeling atm.) 4. What are the nice to haves? 5. How does mDNS cooperate/integrate with IPv6? 6. How should the mDNS system integrate with the rest of the FreeBSD system? I think at minimum anything we import should support nss, but what else do we need here? 7. How should the sysadmin interact with this, and what knobs should they be able to twiddle? (LLA address parameters, definitions of unique services, access limitations ala hosts.allow?) 8. How should applications interact with this system? That includes stuff in the FreeBSD base, and what APIs to publish for third party stuff. Are there well established APIs that we should/must support? 9. At some point we have to bring the ports guys in on this too, with a goal in mind of determining what features we'd need to support in the base to eliminate the need for an mDNS implementation in ports. (The fact that we currently have 2, slightly incompatible implementations in ports now is already giving me a headache.) 10. How do users interact with this? Should there be a utility that allows users to browse the network to see what services are available? ... and that's just off the top of my head. :) In order to move this forward my idea would be to get the answers to these, and any other crucial questions hashed out fairly thoroughly here first. Then we could post a summary to -arch, preferably along with a link to some running code, so that it would get wider (and better) review. So I'm not promising that it'll go in overnight, but I _do_ want something along this line to go in, so as I said, if no one else steps forward, I'm on the case. Brooks, if you're reading this, can I count on you to broach the question about the Apache license in core@? Doug -- This .signature sanitized for your protection From owner-freebsd-net@FreeBSD.ORG Wed Aug 23 19:53:23 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2261F16A4DF; Wed, 23 Aug 2006 19:53:23 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from sccmmhc92.asp.att.net (sccmmhc92.asp.att.net [204.127.203.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7FB7243D45; Wed, 23 Aug 2006 19:53:22 +0000 (GMT) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net ([12.207.12.9]) by sccmmhc92.asp.att.net (sccmmhc92) with ESMTP id <20060823195311m92002s9jee>; Wed, 23 Aug 2006 19:53:21 +0000 Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.13.6/8.13.6) with ESMTP id k7NJqxsC027604; Wed, 23 Aug 2006 14:53:00 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.13.6/8.13.6/Submit) id k7NJqra9027603; Wed, 23 Aug 2006 14:52:53 -0500 (CDT) (envelope-from brooks) Date: Wed, 23 Aug 2006 14:52:53 -0500 From: Brooks Davis To: Doug Barton Message-ID: <20060823195253.GA27482@lor.one-eyed-alien.net> References: <44E9F991.7020309@shapeshifter.se> <44EA1926.2000501@shapeshifter.se> <9C04919EE684029A410DE208@garrett.local> <44EAC40E.9000904@shapeshifter.se> <3E654CC0217F90E20FCD806E@garrett.local> <44EC90B7.6090908@shapeshifter.se> <44ECB0F2.9040300@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tKW2IUtsqtDRztdT" Content-Disposition: inline In-Reply-To: <44ECB0F2.9040300@FreeBSD.org> User-Agent: Mutt/1.5.11 Cc: freebsd-net@freebsd.org, Pat Lashley , Fredrik Lindberg Subject: Re: Zeroconfig and Multicast DNS 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, 23 Aug 2006 19:53:23 -0000 --tKW2IUtsqtDRztdT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Aug 23, 2006 at 12:48:02PM -0700, Doug Barton wrote: > Brooks, if you're reading this, can I count on you to broach the question > about the Apache license in core@? Will do. -- Brooks --tKW2IUtsqtDRztdT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFE7LIUXY6L6fI4GtQRAunjAKDKlCHHxfsAE319o3BXXAMFzPuDnACguqrg pNjibVn6JAiyiYSf6yysL/0= =fWHh -----END PGP SIGNATURE----- --tKW2IUtsqtDRztdT-- From owner-freebsd-net@FreeBSD.ORG Wed Aug 23 19:54:08 2006 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9BEBA16A4DA; Wed, 23 Aug 2006 19:54:08 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3073B43D5C; Wed, 23 Aug 2006 19:53:55 +0000 (GMT) (envelope-from davidch@broadcom.com) Received: from 10.10.64.154 by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.2)); Wed, 23 Aug 2006 12:53:50 -0700 X-Server-Uuid: 450F6D01-B290-425C-84F8-E170B39A25C9 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 71BC12AF; Wed, 23 Aug 2006 12:53:50 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 4D3AC2AE; Wed, 23 Aug 2006 12:53:50 -0700 (PDT) Received: from mail-irva-12.broadcom.com (mail-irva-12.broadcom.com [10.10.64.146]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id EDL92680; Wed, 23 Aug 2006 12:53:50 -0700 (PDT) Received: from NT-IRVA-0750.brcm.ad.broadcom.com (nt-irva-0750 [10.8.194.64]) by mail-irva-12.broadcom.com (Postfix) with ESMTP id E201369CA3; Wed, 23 Aug 2006 12:53:49 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 23 Aug 2006 12:53:49 -0700 Message-ID: <09BFF2FA5EAB4A45B6655E151BBDD90301D43002@NT-IRVA-0750.brcm.ad.broadcom.com> In-Reply-To: <20060823161649.GE76666@cell.sick.ru> Thread-Topic: bge(4) one packet wedge Thread-Index: AcbGz44wS3LCzDADS6Wj0cKiLu257wAGyTrg From: "David Christensen" To: "Gleb Smirnoff" X-TMWD-Spam-Summary: TS=20060823195352; SEV=2.0.2; DFV=A2006082307; IFV=2.0.4,4.0-8; RPD=4.00.0004; ENG=IBF; RPDID=303030312E30413031303230312E34344543423133432E303031372D412D; CAT=NONE; CON=NONE X-MMS-Spam-Filter-ID: A2006082307_4.00.0004_4.0-8 X-WSS-ID: 68F26DC422G1511765-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: brad@openbsd.org, oleg@FreeBSD.org, net@FreeBSD.org Subject: RE: bge(4) one packet wedge 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, 23 Aug 2006 19:54:08 -0000 This "lost interrupt" type of problem is addressed by the use of the status_tag=20 field in the status block. (Listed as bge_rsvd0 in the bge_status_block structure).=20 Everytime the status block is updated a new tag value is written to the status block. =20 When the ISR starts the driver should record the status_tag value. At the end of the ISR, the driver should compare the current status_tag value is the status block with the value recorded on entry to the ISR. If the values are the same then no additional status block updates have occurred so there shouldn't be any packets hanging around. If the values are different then additional packets or completions are waiting around so the ISR should loop around again. At the=20 end of the ISR the driver will write the status_tag value it last handled to a mailbox register, letting the hardware know the last status block update handled. If necessary the hardware will generate a new interrupt and start the process over again. This entire process should be included in the Linux driver, I don't see it being used in the bge driver (bge_intr()). Dave > -----Original Message----- > From: Gleb Smirnoff [mailto:glebius@FreeBSD.org]=20 > Sent: Wednesday, August 23, 2006 9:17 AM > To: David Christensen > Cc: brad@openbsd.org; oleg@FreeBSD.org; net@FreeBSD.org > Subject: bge(4) one packet wedge >=20 > Colleagues, >=20 > I've faced a problem in bge(4) when a single packet is in the RX > ring, but it isn't noticed by the driver. A reception of a packet > triggers interrupt and both packets are processed - an old one > and the new one. >=20 > To reproduce the problem you need to run netperf (from ports > collection): netserver on another host (10.0.0.1) and netperf on > the host, where tested bge(4) is installed - 10.0.0.2. No traffic > except netperf's should flow through this NIC, or the problem won't > be reproduced! >=20 > So, I run netperf client and simultaneously tcpdump on the > another host. After few seconds there is a wedge. The last packet > seen on 10.0.0.1 is the packet sent by 10.0.0.1 to 10.0.0.2. However > it isn't seen on 10.0.0.2. >=20 > Ok, let's look at the receive ring: >=20 > (kgdb) p $sc->bge_rx_saved_considx > $14 =3D 51 > (kgdb) p $sc->bge_ldata.bge_status_block->bge_idx[0].bge_rx_prod_idx > $15 =3D 51 >=20 > Looks like there is nothing to process. >=20 > However, if I run 'ping -c 1 10.0.0.2' I will get an=20 > interrupt and read > two packets: first the old packet, and then recently sent ping. >=20 > --=20 > Totus tuus, Glebius. > GLEBIUS-RIPN GLEB-RIPE >=20 >=20 From owner-freebsd-net@FreeBSD.ORG Wed Aug 23 20:32:41 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0007B16A4E1; Wed, 23 Aug 2006 20:32:40 +0000 (UTC) (envelope-from fli+freebsd-net@shapeshifter.se) Received: from mx1.h3q.net (manticore.shapeshifter.se [212.37.5.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4962B43D53; Wed, 23 Aug 2006 20:32:39 +0000 (GMT) (envelope-from fli+freebsd-net@shapeshifter.se) Received: from localhost (localhost [127.0.0.1]) by mx1.h3q.net (Postfix) with ESMTP id B32C91A78D; Wed, 23 Aug 2006 22:32:37 +0200 (CEST) Received: from mx1.h3q.net ([127.0.0.1]) by localhost (mx1.h3q.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14692-01; Wed, 23 Aug 2006 22:32:36 +0200 (CEST) Received: from [192.168.1.100] (217-208-33-252-o926.tbon.telia.com [217.208.33.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.h3q.net (Postfix) with ESMTP id C89301A751; Wed, 23 Aug 2006 22:32:35 +0200 (CEST) Message-ID: <44ECBB61.9020808@shapeshifter.se> Date: Wed, 23 Aug 2006 22:32:33 +0200 From: Fredrik Lindberg User-Agent: Thunderbird 1.5.0.4 (X11/20060727) MIME-Version: 1.0 To: Doug Barton References: <44E9F991.7020309@shapeshifter.se> <44EA1926.2000501@shapeshifter.se> <9C04919EE684029A410DE208@garrett.local> <44EAC40E.9000904@shapeshifter.se> <3E654CC0217F90E20FCD806E@garrett.local> <44EC90B7.6090908@shapeshifter.se> <44ECB0F2.9040300@FreeBSD.org> In-Reply-To: <44ECB0F2.9040300@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at h3q.net Cc: freebsd-net@freebsd.org Subject: Re: Zeroconfig and Multicast DNS 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, 23 Aug 2006 20:32:41 -0000 Doug Barton wrote: > > I find it very interesting. :) One of my side projects at the moment is to > come further up to speed on the subject of multicast DNS in general, so I'm > following this discussion with a great deal of interest. I'd really like to > see FreeBSD take a lead in this area, since the more research I do the more > I am convinced that this, or something very much like it is the future of > end-user network provisioning. > > If no one else steps forward, I will be glad to lead the charge to get an > implementation of this committed. Before I do though, we'll need to get some > basic questions answered (some of which have already been discussed here). > > 1. What are the other *BSDs doing in this area? NetBSD had a SoC a year ago I think, don't think anything has been imported into their tree. I've used some parts of it in my lla implementation. Don't know about OpenBSD nor about Dragonfly. > 2. What are the linux flavors doing? It appears that the Avahi (http://avahi.org/) responder is the current leader, it's API compatible (client wise) with mDNSResponder. > 3. What is the minimal set of features we should support? (I think this list > starts with LLA, but that's just a gut feeling atm.) At a minimum LLA and basic mDNS (apple has some exotic wide area extensions). LLA is probably easiest to begin with. > 4. What are the nice to haves? IMHO, mDNS. > 5. How does mDNS cooperate/integrate with IPv6? Just as well as with IPv4, at least to my knowledge. > 6. How should the mDNS system integrate with the rest of the FreeBSD system? > I think at minimum anything we import should support nss, but what else do > we need here? A client API compatible with the one from Apples mDNSResponder as it seems to be the de facto standard. The client API header file is BSD-licensed. A nss module would probably be just another responder client, either using Apples API or any API of our choice (depends on how we implement the responder). > 7. How should the sysadmin interact with this, and what knobs should they be > able to twiddle? (LLA address parameters, definitions of unique services, > access limitations ala hosts.allow?) As for lla, it's really zeroconfig by nature and more or less dhcp without a server. A suitable configuration is something such as LLA in the ifconfig_if0="" line in rc.conf (similar to DHCP or WPA). As for mDNS/SD I think a generic responderd.conf/mdns.conf file should be available where you can configure "static" dns records. Programs will be able to register/announce records through the client API (it talks to the responder via a unix pipe socket). Various utilities should be available so that an administrator is able to add/remove records from the command line and via scripts. > 8. How should applications interact with this system? That includes stuff in > the FreeBSD base, and what APIs to publish for third party stuff. Are there > well established APIs that we should/must support? It's best to go with Apples API from mDNSResponder. > 9. At some point we have to bring the ports guys in on this too, with a goal > in mind of determining what features we'd need to support in the base to > eliminate the need for an mDNS implementation in ports. (The fact that we > currently have 2, slightly incompatible implementations in ports now is > already giving me a headache.) See previous answer. Supporting different APIs might be possible but not as a start. > 10. How do users interact with this? Should there be a utility that allows > users to browse the network to see what services are available? > This is where the Service Discovery protocol comes in, it runs on top of mDNS and are basically just dns records peers announce when they would like to tell the world about services they are providing. Having such utility would probably be nice. As for mDNS and hostname in generic, users would interact with them just as with any other dns records or name. > ... and that's just off the top of my head. :) > > In order to move this forward my idea would be to get the answers to these, > and any other crucial questions hashed out fairly thoroughly here first. > Then we could post a summary to -arch, preferably along with a link to some > running code, so that it would get wider (and better) review. > > So I'm not promising that it'll go in overnight, but I _do_ want something > along this line to go in, so as I said, if no one else steps forward, I'm on > the case. It's nice that others have seen the zeroconfig light :) > > Brooks, if you're reading this, can I count on you to broach the question > about the Apache license in core@? > I've already written quite a lot of BSD licensed code and some parts of Apples mDNSResponder is under a BSD license (client api part). If we mix these together we might be able to avoid the Apache license, but it's of course nice to get a definitive answer on the Apache license. (And maybe my code turns out to be useless... :)) Fredrik Lindberg From owner-freebsd-net@FreeBSD.ORG Wed Aug 23 21:13:29 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7B0F616A4DD; Wed, 23 Aug 2006 21:13:29 +0000 (UTC) (envelope-from patl+freebsd@volant.org) Received: from smtp.volant.org (gate.volant.org [207.111.218.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id C4B6C43D45; Wed, 23 Aug 2006 21:13:28 +0000 (GMT) (envelope-from patl+freebsd@volant.org) Received: from adsl-065-081-071-131.sip.gnv.bellsouth.net ([65.81.71.131] helo=[192.168.1.121]) by smtp.volant.org with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34 (FreeBSD)) id 1GG05Q-000BKd-A3; Wed, 23 Aug 2006 14:16:52 -0700 Date: Wed, 23 Aug 2006 14:12:20 -0400 From: Pat Lashley To: Doug Barton , Fredrik Lindberg Message-ID: In-Reply-To: <44ECB0F2.9040300@FreeBSD.org> References: <44E9F991.7020309@shapeshifter.se> <44EA1926.2000501@shapeshifter.se> <9C04919EE684029A410DE208@garrett.local> <44EAC40E.9000904@shapeshifter.se> <3E654CC0217F90E20FCD806E@garrett.local> <44EC90B7.6090908@shapeshifter.se> <44ECB0F2.9040300@FreeBSD.org> X-Mailer: Mulberry/4.0.0 (Mac OS X) MIME-Version: 1.0 X-Scan-Signature: 2b3bb6b7b9800778ff3876abd230e8b8c1994aa6 X-Spam-User: nobody X-Spam-Score: -4.2 (----) X-Spam-Score-Int: -41 X-Spam-Report: This mail has matched the spam-filter tests listed below. See http://spamassassin.org/tag/ for details about the specific tests reported. In general, the higher the number of total points, the more likely that it actually is spam. (The 'required' number of points listed below is the arbitrary number above which the message is normally considered spam.) Content analysis details: (-4.2 points total, 5.0 required) 0.1 HTML_MESSAGE BODY: HTML included in message 0.1 HTML_FONTCOLOR_RED BODY: HTML font color is red -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.4 DATE_IN_PAST_03_06 Date: is 3 to 6 hours before Received: date 0.1 AWL AWL: Auto-whitelist adjustment Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: Zeroconfig and Multicast DNS 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, 23 Aug 2006 21:13:29 -0000 > If no one else steps forward, I will be glad to lead the charge to get an > implementation of this committed. Before I do though, we'll need to get some > basic questions answered (some of which have already been discussed here). > > 1. What are the other *BSDs doing in this area? > 2. What are the linux flavors doing? > 3. What is the minimal set of features we should support? (I think this list > starts with LLA, but that's just a gut feeling atm.) I would agree that LLA is part of the minimal set; and as I mentioned before, it is the only part for which there is currently no FreeBSD solution. It should be possible to enable LLA on a per-NIC basis in rc.conf; and it should be possible to have both LLA and non-LLA addresses on the same port so that a FreeBSD host can easily operate in a mixed environment. (This also makes it easier for portable machines to handle being moved between a zeroconf-based environment and a more traditional DHCP environment.) Determining a minimal set of mDNS-based features is a little more difficult. Unless I've missed something, I'd say that the mDNSResponder feature set isn't quite sufficient; because it provides no mechanism to advertise services which are provided by daemons that aren't explicitly mDNS-aware. (But adding such a utility using libdns_sd should be trivial.) I really think that we need to treat the LLA and mDNS portions of Zeroconf as separate projects. Defining the feature set and system interactions for LLA should be much easier than for mDNS; so hopefully we can get the code for that integrated while still working on the mDNS portion. > 4. What are the nice to haves? For the mDNS-based portsions, see the Avahi feature and to-do lists... :-) (Some more FreeBSD-specific items are mentioned below.) > 5. How does mDNS cooperate/integrate with IPv6? It should be possible to separately enable/disable IPv4 and IPv6 support in our mdns daemon. Other than that, it is my understanding that there really isn't any significant difference between them as far as mDNS and mDNS-SD goes. (As most of you are aware, there is no need for an IPv6 Link Local Address daemon because Link Local addresses are already built into IPv6.) There is the question of whether to propigate mDNS records between IPv4 and IPv6. The current best advice seems to be to avoid that except in unusual circumstances. So if we allow it at all, it should be controlled by a knob that defaults to OFF. > 6. How should the mDNS system integrate with the rest of the FreeBSD system? > I think at minimum anything we import should support nss, but what else do > we need here? A utility to add/remove service advertisements via the command-line; and integration of it into the rc.d scripts of our service daemons. (At least until those daemons are made mDNS-aware.) A command-line service browser would also be nice. I'm not sure whether we want to try to do things like add advertised lpd services to the printer list; or if it would be better to leave that sort of thing to the ports. (Where it is already being handled by at least parts of GNOME, KDE, etc.) > 7. How should the sysadmin interact with this, and what knobs should they be > able to twiddle? (LLA address parameters, definitions of unique services, > access limitations ala hosts.allow?) There really aren't any LLA address parameters to twiddle. The address range is specified by the RFC. You'll want to be able to enable/disable LLA on a per-interface basis. You may want to be able to specify whether to obtain/keep an LLA if an other IP address is obtained for the interface via some other mechanism. It would be nice to be able to specify which interfaces the mDNS should operate on; but I'm not sure whether it would be cleaner to make it a list of those to include or those to exclude. In either case, wild cards should be allowed to handle dynamic interfaces. (E.g., You might want to run and propigate mDNS across a tun-based VPN, despite the potential latency issues that would dictate that the default should be no mDNS for any type of Point-to-Point link.) For a multi-homed machine, you want to be able to specify whether or not to propagate the LLA and mDNS info across both links or treat them separately. (The default should be separate; propagation must be handled with extreme care to avoid problems.) I would add a knob to each service to say whether or not it should advertise via mDNS. (E.g., sshd_mdns_advertise="YES") For services that use the mDNS library, that knob can be converted into a command-line parameter; for others, a small block in the rc.d script that uses the utility I mentioned above. The existing access limitation mechanisms should be sufficient. > 8. How should applications interact with this system? That includes stuff in > the FreeBSD base, and what APIs to publish for third party stuff. Are there > well established APIs that we should/must support? The mDNSResponder API seems to be a sort of least-common-denominator. Avahi provides API compatibility shims for it. But KDE, GNOME, Apache, et. al. seem to have gone with Avahi. We should strive for API/ABI compatibility with one or both of those. > 9. At some point we have to bring the ports guys in on this too, with a goal > in mind of determining what features we'd need to support in the base to > eliminate the need for an mDNS implementation in ports. (The fact that we > currently have 2, slightly incompatible implementations in ports now is > already giving me a headache.) Make that three: mDNSResponder, gmdns, and avahi. As I mentioned above, Avahi has mDNSResponder API compatibility; and appears to be the one most widely used by major projects. If we want to eliminate mDNS ports; then I think we need to go for supporting both the mDNSResponder and Avahi APIs. But note that Avahi includes some Gtk-based tools; so we'd probably still need an 'avahi-tools' port to provide the bits that we don't support in our implementation. > 10. How do users interact with this? Should there be a utility that allows > users to browse the network to see what services are available? Yes, a fairly simple command-line browser would be nice; especially if the output is designed to be easily parsed and handled by scripts. -Pat From owner-freebsd-net@FreeBSD.ORG Wed Aug 23 21:21:45 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5645F16A4E7; Wed, 23 Aug 2006 21:21:45 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from sccmmhc92.asp.att.net (sccmmhc92.asp.att.net [204.127.203.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4661143D62; Wed, 23 Aug 2006 21:21:36 +0000 (GMT) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net ([12.207.12.9]) by sccmmhc92.asp.att.net (sccmmhc92) with ESMTP id <20060823212133m92002tin3e>; Wed, 23 Aug 2006 21:21:33 +0000 Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.13.6/8.13.6) with ESMTP id k7NLLPQC028427; Wed, 23 Aug 2006 16:21:26 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.13.6/8.13.6/Submit) id k7NLLAEQ028426; Wed, 23 Aug 2006 16:21:10 -0500 (CDT) (envelope-from brooks) Date: Wed, 23 Aug 2006 16:21:10 -0500 From: Brooks Davis To: Pat Lashley Message-ID: <20060823212110.GD27961@lor.one-eyed-alien.net> References: <44E9F991.7020309@shapeshifter.se> <44EA1926.2000501@shapeshifter.se> <9C04919EE684029A410DE208@garrett.local> <44EAC40E.9000904@shapeshifter.se> <3E654CC0217F90E20FCD806E@garrett.local> <44EC90B7.6090908@shapeshifter.se> <44ECB0F2.9040300@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UfEAyuTBtIjiZzX6" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11 Cc: freebsd-net@freebsd.org, Doug Barton , Fredrik Lindberg Subject: Re: Zeroconfig and Multicast DNS 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, 23 Aug 2006 21:21:45 -0000 --UfEAyuTBtIjiZzX6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 23, 2006 at 02:12:20PM -0400, Pat Lashley wrote: > >If no one else steps forward, I will be glad to lead the charge to get an > >implementation of this committed. Before I do though, we'll need to get= =20 > >some > >basic questions answered (some of which have already been discussed here= ). > > > >1. What are the other *BSDs doing in this area? > >2. What are the linux flavors doing? > >3. What is the minimal set of features we should support? (I think this= =20 > >list > >starts with LLA, but that's just a gut feeling atm.) >=20 > I would agree that LLA is part of the minimal set; and as I mentioned=20 > before, it is the only part for which there is currently no FreeBSD=20 > solution. It should be possible to enable LLA on a per-NIC basis in=20 > rc.conf; and it should be possible to have both LLA and non-LLA addresses= =20 > on the same port so that a FreeBSD host can easily operate in a mixed=20 > environment. (This also makes it easier for portable machines to handle= =20 > being moved between a zeroconf-based environment and a more traditional= =20 > DHCP environment.) I don't see how we can do the fallback stuff with our current infrastructure. You could do it with profile.sh, but our current infrastructure isn't really suited to it. In some ways what we really need is an all knowing IPv4 address configuration program that can probe the link and decide if it should a) use a static IP, b) use DHCP, or c) use an LLA. It's possible we could do this in a shell script, but I'm not sure we'd want to. -- Brooks --UfEAyuTBtIjiZzX6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFE7MbFXY6L6fI4GtQRApwfAKC015TZUTHng/4OPmCqYTo8UWOfVQCeLZcz wYBpTfHzggq7ThCTpO6OgAc= =umaF -----END PGP SIGNATURE----- --UfEAyuTBtIjiZzX6-- From owner-freebsd-net@FreeBSD.ORG Wed Aug 23 21:51:02 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CEF5E16A4E7; Wed, 23 Aug 2006 21:51:02 +0000 (UTC) (envelope-from patl+freebsd@volant.org) Received: from smtp.volant.org (gate.volant.org [207.111.218.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1660643D46; Wed, 23 Aug 2006 21:51:01 +0000 (GMT) (envelope-from patl+freebsd@volant.org) Received: from adsl-065-081-071-131.sip.gnv.bellsouth.net ([65.81.71.131] helo=[192.168.1.121]) by smtp.volant.org with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34 (FreeBSD)) id 1GG0g1-000Bf9-9i; Wed, 23 Aug 2006 14:54:26 -0700 Date: Wed, 23 Aug 2006 14:50:09 -0400 From: Pat Lashley To: Fredrik Lindberg , Doug Barton Message-ID: <5D7785ADC030FEBFB9A5E69D@garrett.local> In-Reply-To: <44ECBB61.9020808@shapeshifter.se> References: <44E9F991.7020309@shapeshifter.se> <44EA1926.2000501@shapeshifter.se> <9C04919EE684029A410DE208@garrett.local> <44EAC40E.9000904@shapeshifter.se> <3E654CC0217F90E20FCD806E@garrett.local> <44EC90B7.6090908@shapeshifter.se> <44ECB0F2.9040300@FreeBSD.org> <44ECBB61.9020808@shapeshifter.se> X-Mailer: Mulberry/4.0.0 (Mac OS X) MIME-Version: 1.0 X-Scan-Signature: 5cd040c481e84414b1546b196443c1bb3fddc810 X-Spam-User: nobody X-Spam-Score: -3.1 (---) X-Spam-Score-Int: -30 X-Spam-Report: This mail has matched the spam-filter tests listed below. See http://spamassassin.org/tag/ for details about the specific tests reported. In general, the higher the number of total points, the more likely that it actually is spam. (The 'required' number of points listed below is the arbitrary number above which the message is normally considered spam.) Content analysis details: (-3.1 points total, 5.0 required) 2.2 DOMAIN_BODY BODY: Domain registration spam body 0.1 HTML_MESSAGE BODY: HTML included in message 0.1 HTML_FONTCOLOR_RED BODY: HTML font color is red -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.4 DATE_IN_PAST_03_06 Date: is 3 to 6 hours before Received: date -1.0 AWL AWL: Auto-whitelist adjustment Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: Zeroconfig and Multicast DNS 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, 23 Aug 2006 21:51:02 -0000 > > 2. What are the linux flavors doing? > > It appears that the Avahi (http://avahi.org/) responder is the > current leader, it's API compatible (client wise) with mDNSResponder. It is my impression that the mDNSResponder API compatibility lib/shim is a build-time option and not actually used by the rest of the Avahi code. >> 4. What are the nice to haves? > > IMHO, mDNS. One of the things that I forgot to mention is that it would be nice if the mDNS handled both the .local domain and one or more specific domains easily. In particular, if I have a host named 'mumble' and tell mDNS that my domain is lan.example.com; then I would like both 'mumble.local' and 'mumble.lan.example.com' to resolve (and be advertised) via mDNS. Similarly for any services advertised on that host. And I'm assuming that once we have Zeroconf support, it will be in the configuration used by sysinstall on the installation ISO image... (It shouldn't have much, if anything, to advertise except a hostname and IP address; but could make good use of LLA and service discovery.) > > 7. How should the sysadmin interact with this, and what knobs should they be > > able to twiddle? (LLA address parameters, definitions of unique services, > > access limitations ala hosts.allow?) > > As for lla, it's really zeroconfig by nature and more or less dhcp > without a server. A suitable configuration is something such as LLA in > the ifconfig_if0="" line in rc.conf (similar to DHCP or WPA). At my previous job, I worked with the busybox zcif LLA implementation for an embedded client. I found it annoying that there was no way to have a single interface with both LLA and non-LLA addresses. I would argue strongly for an rc.conf setup that allows us to specify that LLA is to be performed on an interface, even if an address is obtained via some other mechanism. In particular, it would be nice to be able to specify both LLA and DHCP. (And to specify that DHCP failure is OK.) > As for mDNS/SD I think a generic responderd.conf/mdns.conf file should > be available where you can configure "static" dns records. I would really rather see the service advertisement done in each service's rc.d script. That has the advantage of not requiring the mdns.conf file to be updated if the _enable knob is changed in /etc/rc.conf. It also makes it easy to add a line to revoke the advertisement in the rc.d script's 'stop' action. That said, static service advertisement via the mdns.conf file is useful when advertising on behalf of of a system or embedded device that doesn't have native mDNS support. (E.g., An older network-attached printer.) The mdns.conf can also be used to advertise host records for hosts that don't support mDNS. But again, it would be nice to have a config flag that just says 'advertise everything in /etc/hosts' in addition to a way to list individual entries. > Programs will be able to register/announce records through the client > API (it talks to the responder via a unix pipe socket). Right. Applications that are mDNS-aware just use the library API to announce/revoke their availability and to browse for services they may want to use. And eventually, I think that we want to integrate mDNS-awareness in all of our bundled services and any apps for which service browsing makes sense. The rc.d script utility calls mentioned above are intended to handle the transition period while we have the basic mDNS functionality but haven't yet converted all of the services to use it. > Various utilities should be available so that an administrator is able > to add/remove records from the command line and via scripts. Right. Also to browse both host records and service advertisements. > > 8. How should applications interact with this system? That includes stuff in > > the FreeBSD base, and what APIs to publish for third party stuff. Are there > > well established APIs that we should/must support? > > It's best to go with Apples API from mDNSResponder. It's not clear to me yet whether it is better to do that or to go with the Avahi API; or to provide both. (I haven't actually looked at either; so I don't know just how they differ.) > > 9. At some point we have to bring the ports guys in on this too, with a goal > > in mind of determining what features we'd need to support in the base to > > eliminate the need for an mDNS implementation in ports. (The fact that we > > currently have 2, slightly incompatible implementations in ports now is > > already giving me a headache.) > > See previous answer. Supporting different APIs might be possible but > not as a start. Again, it isn't clear just how different the two main API sets are; or how hard it would be to support both. It's quite possible that one set of the API would just turn into a set of shim calls that invoke the other one. > > 10. How do users interact with this? Should there be a utility that allows > > users to browse the network to see what services are available? > > This is where the Service Discovery protocol comes in, it runs on top of > mDNS and are basically just dns records peers announce when they would > like to tell the world about services they are providing. > Having such utility would probably be nice. I see this as mainly important for sysadmins. There's a good chance that end users will have GNOME and/or KDE installed; and already have a GUI-based service browser. > As for mDNS and hostname in generic, users would interact with them just > as with any other dns records or name. Right. Except for the additional bit of knowledge about the .local domain. > It's nice that others have seen the zeroconfig light :) Hear! Hear! -Pat From owner-freebsd-net@FreeBSD.ORG Wed Aug 23 22:08:28 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7B2ED16A4DD; Wed, 23 Aug 2006 22:08:28 +0000 (UTC) (envelope-from patl+freebsd@volant.org) Received: from smtp.volant.org (gate.volant.org [207.111.218.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id E826B43D49; Wed, 23 Aug 2006 22:08:27 +0000 (GMT) (envelope-from patl+freebsd@volant.org) Received: from adsl-065-081-071-131.sip.gnv.bellsouth.net ([65.81.71.131] helo=[192.168.1.121]) by smtp.volant.org with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34 (FreeBSD)) id 1GG0wq-000Bql-Aw; Wed, 23 Aug 2006 15:11:49 -0700 Date: Wed, 23 Aug 2006 15:07:32 -0400 From: Pat Lashley To: Brooks Davis Message-ID: In-Reply-To: <20060823212110.GD27961@lor.one-eyed-alien.net> References: <44E9F991.7020309@shapeshifter.se> <44EA1926.2000501@shapeshifter.se> <9C04919EE684029A410DE208@garrett.local> <44EAC40E.9000904@shapeshifter.se> <3E654CC0217F90E20FCD806E@garrett.local> <44EC90B7.6090908@shapeshifter.se> <44ECB0F2.9040300@FreeBSD.org> <20060823212110.GD27961@lor.one-eyed-alien.net> X-Mailer: Mulberry/4.0.0 (Mac OS X) MIME-Version: 1.0 X-Scan-Signature: 1b8fd31277999b768e0ff02d71d8f20cb832ef7c X-Spam-User: nobody X-Spam-Score: -4.1 (----) X-Spam-Score-Int: -40 X-Spam-Report: This mail has matched the spam-filter tests listed below. See http://spamassassin.org/tag/ for details about the specific tests reported. In general, the higher the number of total points, the more likely that it actually is spam. (The 'required' number of points listed below is the arbitrary number above which the message is normally considered spam.) Content analysis details: (-4.1 points total, 5.0 required) 0.1 HTML_MESSAGE BODY: HTML included in message 0.1 HTML_FONTCOLOR_RED BODY: HTML font color is red -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.4 DATE_IN_PAST_03_06 Date: is 3 to 6 hours before Received: date 0.2 AWL AWL: Auto-whitelist adjustment Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, Doug Barton , Fredrik Lindberg Subject: Re: Zeroconfig and Multicast DNS 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, 23 Aug 2006 22:08:28 -0000 > > I would agree that LLA is part of the minimal set; and as I mentioned > > before, it is the only part for which there is currently no FreeBSD > > solution. It should be possible to enable LLA on a per-NIC basis in > > rc.conf; and it should be possible to have both LLA and non-LLA addresses > > on the same port so that a FreeBSD host can easily operate in a mixed > > environment. (This also makes it easier for portable machines to handle > > being moved between a zeroconf-based environment and a more traditional > > DHCP environment.) > > I don't see how we can do the fallback stuff with our current > infrastructure. You could do it with profile.sh, but our current > infrastructure isn't really suited to it. In some ways what we really > need is an all knowing IPv4 address configuration program that can probe > the link and decide if it should a) use a static IP, b) use DHCP, or c) > use an LLA. It's possible we could do this in a shell script, but I'm > not sure we'd want to. I don't think those should necessarily be mutually exclusive. I'd much rather see something that uses aliases so that I can easily have both an LLA and a non-LLA address on the same interface. The only potentially tricky part is that the RFC requires (quite rightly) that in such a situation, the non-LLA address be preferred. If it were strictly a 'pick one' situation; then we could just extend our current setup so that the DHCP client could be told to fall back to LLA if it can't obtain a lease. I suspect that it will be less common to want to use both an LL/DHCP address and a static address; but I certainly wouldn't rule it out. (In fact, now that I think about it, I'm likely to run into that situation during the transition of my LAN from static RFC-1918 addresses to LLA.) -Pat From owner-freebsd-net@FreeBSD.ORG Wed Aug 23 22:18:54 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D0BE316A591; Wed, 23 Aug 2006 22:18:54 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from sccmmhc91.asp.att.net (sccmmhc91.asp.att.net [204.127.203.211]) by mx1.FreeBSD.org (Postfix) with ESMTP id B1B4043D6B; Wed, 23 Aug 2006 22:18:42 +0000 (GMT) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net ([12.207.12.9]) by sccmmhc91.asp.att.net (sccmmhc91) with ESMTP id <20060823221840m910087qh3e>; Wed, 23 Aug 2006 22:18:41 +0000 Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.13.6/8.13.6) with ESMTP id k7NMIcwT029026; Wed, 23 Aug 2006 17:18:38 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.13.6/8.13.6/Submit) id k7NMIaiT029025; Wed, 23 Aug 2006 17:18:36 -0500 (CDT) (envelope-from brooks) Date: Wed, 23 Aug 2006 17:18:36 -0500 From: Brooks Davis To: Pat Lashley Message-ID: <20060823221835.GA28978@lor.one-eyed-alien.net> References: <44EA1926.2000501@shapeshifter.se> <9C04919EE684029A410DE208@garrett.local> <44EAC40E.9000904@shapeshifter.se> <3E654CC0217F90E20FCD806E@garrett.local> <44EC90B7.6090908@shapeshifter.se> <44ECB0F2.9040300@FreeBSD.org> <20060823212110.GD27961@lor.one-eyed-alien.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="d6Gm4EdcadzBjdND" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11 Cc: freebsd-net@freebsd.org, Doug Barton , Fredrik Lindberg Subject: Re: Zeroconfig and Multicast DNS 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, 23 Aug 2006 22:18:55 -0000 --d6Gm4EdcadzBjdND Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 23, 2006 at 03:07:32PM -0400, Pat Lashley wrote: > >> I would agree that LLA is part of the minimal set; and as I mentioned > >> before, it is the only part for which there is currently no FreeBSD > >> solution. It should be possible to enable LLA on a per-NIC basis in > >> rc.conf; and it should be possible to have both LLA and non-LLA addres= ses > >> on the same port so that a FreeBSD host can easily operate in a mixed > >> environment. (This also makes it easier for portable machines to handle > >> being moved between a zeroconf-based environment and a more traditional > >> DHCP environment.) > > > >I don't see how we can do the fallback stuff with our current > >infrastructure. You could do it with profile.sh, but our current > >infrastructure isn't really suited to it. In some ways what we really > >need is an all knowing IPv4 address configuration program that can probe > >the link and decide if it should a) use a static IP, b) use DHCP, or c) > >use an LLA. It's possible we could do this in a shell script, but I'm > >not sure we'd want to. >=20 > I don't think those should necessarily be mutually exclusive. I'd much= =20 > rather see something that uses aliases so that I can easily have both an= =20 > LLA and a non-LLA address on the same interface. The only potentially=20 > tricky part is that the RFC requires (quite rightly) that in such a=20 > situation, the non-LLA address be preferred. If it were strictly a 'pick= =20 > one' situation; then we could just extend our current setup so that the= =20 > DHCP client could be told to fall back to LLA if it can't obtain a lease. >=20 > I suspect that it will be less common to want to use both an LL/DHCP=20 > address and a static address; but I certainly wouldn't rule it out. (In= =20 > fact, now that I think about it, I'm likely to run into that situation=20 > during the transition of my LAN from static RFC-1918 addresses to LLA.) DHCP+static is rather weird, but common enough that we do support it. I suspect LLA with other address types is also of use at least some of the time so we should ideally support it. Actually if we don't mind always configuring a LLA I think we might support be OK right now as long as the LLA daemon leaves non-LLA addresses alone. The one thing I'd be worried about is how the socket code handles connect() requests. My hope would be that it would pick the address that goes with the router to be used and thus the LLA would never be the source of a packet going to a non-LLA address in normal circumstances. -- Brooks --d6Gm4EdcadzBjdND Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFE7NQ7XY6L6fI4GtQRAvqkAJ92S8/0ICtCbVazU33uU8bji3XsoQCgkEAk vGlxsju/ZAdu9OZ9GIwcY44= =/9rs -----END PGP SIGNATURE----- --d6Gm4EdcadzBjdND-- From owner-freebsd-net@FreeBSD.ORG Wed Aug 23 22:56:08 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7155016A4DD; Wed, 23 Aug 2006 22:56:08 +0000 (UTC) (envelope-from patl@volant.org) Received: from smtp.volant.org (gate.volant.org [207.111.218.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8FCB043D49; Wed, 23 Aug 2006 22:55:49 +0000 (GMT) (envelope-from patl@volant.org) Received: from adsl-065-081-071-131.sip.gnv.bellsouth.net ([65.81.71.131] helo=[192.168.1.121]) by smtp.volant.org with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34 (FreeBSD)) id 1GG1gj-000CIT-R7; Wed, 23 Aug 2006 15:59:13 -0700 Date: Wed, 23 Aug 2006 15:54:59 -0400 From: Pat Lashley To: Brooks Davis Message-ID: <23D2619F6BACE4E728178EE5@garrett.local> In-Reply-To: <20060823221835.GA28978@lor.one-eyed-alien.net> References: <44EA1926.2000501@shapeshifter.se> <9C04919EE684029A410DE208@garrett.local> <44EAC40E.9000904@shapeshifter.se> <3E654CC0217F90E20FCD806E@garrett.local> <44EC90B7.6090908@shapeshifter.se> <44ECB0F2.9040300@FreeBSD.org> <20060823212110.GD27961@lor.one-eyed-alien.net> <20060823221835.GA28978@lor.one-eyed-alien.net> X-Mailer: Mulberry/4.0.0 (Mac OS X) MIME-Version: 1.0 X-Scan-Signature: fabf82d965fcfa3dfd949ed30a634791b406de44 X-Spam-User: nobody X-Spam-Score: -2.4 (--) X-Spam-Score-Int: -23 X-Spam-Report: This mail has matched the spam-filter tests listed below. See http://spamassassin.org/tag/ for details about the specific tests reported. In general, the higher the number of total points, the more likely that it actually is spam. (The 'required' number of points listed below is the arbitrary number above which the message is normally considered spam.) Content analysis details: (-2.4 points total, 5.0 required) 0.1 HTML_MESSAGE BODY: HTML included in message 0.1 HTML_FONTCOLOR_RED BODY: HTML font color is red -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.4 DATE_IN_PAST_03_06 Date: is 3 to 6 hours before Received: date 1.8 AWL AWL: Auto-whitelist adjustment Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, Doug Barton , Fredrik Lindberg Subject: Re: Zeroconfig and Multicast DNS 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, 23 Aug 2006 22:56:08 -0000 > DHCP+static is rather weird, but common enough that we do support it. I > suspect LLA with other address types is also of use at least some > of the time so we should ideally support it. Actually if we don't mind > always configuring a LLA I think we might support be OK right now as > long as the LLA daemon leaves non-LLA addresses alone. The LLA daemon really needs to restrict itself to the LL IP range anyway to be compliant. > The one thing > I'd be worried about is how the socket code handles connect() requests. > My hope would be that it would pick the address that goes with the > router to be used and thus the LLA would never be the source of a packet > going to a non-LLA address in normal circumstances. The RFC is pretty explicit about the need to prefer non-LLA addresses. We may need to put some explicit checks in the connect() code to enforce that preference in the aliased case. The trick, of course, is to recognize those cases where the LLA address must be used anyway. Hmmm. Interesting routing problem. Basically, we need to prefer a route that doesn't use the LLA (unless the destination is in an LLA); but still handle the edge cases like having the default route be through an LLA-only-connected router. (Which MUST do NAT...) We also need to keep an eye towards dynamic roaming. One scenario is a campus composed of multiple Link Local zones and WiFi. As you move around the campus with your (running) laptop, it will have to re-negotiate/defend its LLA; and may need to obtain a different one. The address of the default router is also likely to change as it moves from one zone to another. Of course, in that scenario it doesn't matter whether you have any non-LLA IP addresses; since you won't be using them. BUT if you add in a mix of non-LLA addresses advertised as servers; the routing adjustments could become quite interesting... Some of the problems raised by roaming scenaria need not be addressed immediately; but we do need to keep them in mind during the design phase to ensure that our solution to the basic LLA/mDNS issues doesn't make the roaming issues even harder to handle. -Pat From owner-freebsd-net@FreeBSD.ORG Wed Aug 23 23:56:51 2006 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3E40B16A4E2; Wed, 23 Aug 2006 23:56:51 +0000 (UTC) (envelope-from oleg@lath.rinet.ru) Received: from lath.rinet.ru (lath.rinet.ru [195.54.192.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A0D243D8A; Wed, 23 Aug 2006 23:56:42 +0000 (GMT) (envelope-from oleg@lath.rinet.ru) Received: from lath.rinet.ru (localhost [127.0.0.1]) by lath.rinet.ru (8.13.6/8.13.6) with ESMTP id k7NNuXf3027269 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Aug 2006 03:56:33 +0400 (MSD) (envelope-from oleg@lath.rinet.ru) Received: (from oleg@localhost) by lath.rinet.ru (8.13.6/8.13.6/Submit) id k7NNuWOS027268; Thu, 24 Aug 2006 03:56:32 +0400 (MSD) (envelope-from oleg) Date: Thu, 24 Aug 2006 03:56:32 +0400 From: Oleg Bulyzhin To: David Christensen Message-ID: <20060823235632.GA25876@lath.rinet.ru> References: <20060823161649.GE76666@cell.sick.ru> <09BFF2FA5EAB4A45B6655E151BBDD90301D43002@NT-IRVA-0750.brcm.ad.broadcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <09BFF2FA5EAB4A45B6655E151BBDD90301D43002@NT-IRVA-0750.brcm.ad.broadcom.com> User-Agent: Mutt/1.5.11 Cc: brad@openbsd.org, Gleb Smirnoff , net@FreeBSD.org Subject: Re: bge(4) one packet wedge 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, 23 Aug 2006 23:56:51 -0000 On Wed, Aug 23, 2006 at 12:53:49PM -0700, David Christensen wrote: > This "lost interrupt" type of problem is addressed by the use of the > status_tag > field in the status block. (Listed as bge_rsvd0 in the bge_status_block > structure). > Everytime the status block is updated a new tag value is written to the > status block. > When the ISR starts the driver should record the status_tag value. At > the end > of the ISR, the driver should compare the current status_tag value is > the status > block with the value recorded on entry to the ISR. If the values are > the same > then no additional status block updates have occurred so there shouldn't > be > any packets hanging around. If the values are different then additional > packets > or completions are waiting around so the ISR should loop around again. > At the > end of the ISR the driver will write the status_tag value it last > handled to a > mailbox register, letting the hardware know the last status block update > handled. > If necessary the hardware will generate a new interrupt and start the > process over > again. > > This entire process should be included in the Linux driver, I don't see > it being > used in the bge driver (bge_intr()). > > Dave > Could you please answer few questions? 1) I've found status tag is returned in status block even if bit 9 of Misc. Host Control Register is not set, is it ok? 2) Status tag is returned in bits 0-7 of status tag field of status block, as long as i know it should be returned in bits 31-24, is it ok? 3) If i try to return processed tag (at the end of ISR) in Mailbox 0 register: CSR_WRITE_4(sc, BGE_MBX_IRQ0_LO, status_tag << 24); it would lead to disabled interrupts. I've thought this should not happen cause in_isr bits (0-23) are cleared. -- Oleg. From owner-freebsd-net@FreeBSD.ORG Thu Aug 24 00:54:43 2006 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1EA1B16A4E2; Thu, 24 Aug 2006 00:54:43 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 08BE343D46; Thu, 24 Aug 2006 00:54:41 +0000 (GMT) (envelope-from davidch@broadcom.com) Received: from 10.10.64.154 by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.2)); Wed, 23 Aug 2006 17:54:27 -0700 X-Server-Uuid: 450F6D01-B290-425C-84F8-E170B39A25C9 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 294E52B0; Wed, 23 Aug 2006 17:54:27 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 0354C2AE; Wed, 23 Aug 2006 17:54:26 -0700 (PDT) Received: from mail-irva-12.broadcom.com (mail-irva-12.broadcom.com [10.10.64.146]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id EDM54361; Wed, 23 Aug 2006 17:54:26 -0700 (PDT) Received: from NT-IRVA-0750.brcm.ad.broadcom.com (nt-irva-0750 [10.8.194.64]) by mail-irva-12.broadcom.com (Postfix) with ESMTP id 9896469CA3; Wed, 23 Aug 2006 17:54:26 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 23 Aug 2006 17:54:24 -0700 Message-ID: <09BFF2FA5EAB4A45B6655E151BBDD90301D4312A@NT-IRVA-0750.brcm.ad.broadcom.com> In-Reply-To: <20060823235632.GA25876@lath.rinet.ru> Thread-Topic: bge(4) one packet wedge Thread-Index: AcbHD8lAhIzApWSdQtSWSBK2ikEurwABY7LQ From: "David Christensen" To: "Oleg Bulyzhin" X-TMWD-Spam-Summary: TS=20060824005428; SEV=2.0.2; DFV=A2006082311; IFV=2.0.4,4.0-8; RPD=4.00.0004; ENG=IBF; RPDID=303030312E30413031303230352E34344543463742302E303032392D412D; CAT=NONE; CON=NONE X-MMS-Spam-Filter-ID: A2006082311_4.00.0004_4.0-8 X-WSS-ID: 68F2274922G1589132-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: brad@openbsd.org, Gleb Smirnoff , net@FreeBSD.org Subject: RE: bge(4) one packet wedge 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, 24 Aug 2006 00:54:43 -0000 > On Wed, Aug 23, 2006 at 12:53:49PM -0700, David Christensen wrote: > > This "lost interrupt" type of problem is addressed by the use of the > > status_tag=20 > > field in the status block. (Listed as bge_rsvd0 in the=20 > bge_status_block > > structure).=20 > > Everytime the status block is updated a new tag value is=20 > written to the > > status block. =20 > > When the ISR starts the driver should record the status_tag=20 > value. At > > the end > > of the ISR, the driver should compare the current=20 > status_tag value is > > the status > > block with the value recorded on entry to the ISR. If the=20 > values are > > the same > > then no additional status block updates have occurred so=20 > there shouldn't > > be > > any packets hanging around. If the values are different=20 > then additional > > packets > > or completions are waiting around so the ISR should loop=20 > around again. > > At the=20 > > end of the ISR the driver will write the status_tag value it last > > handled to a > > mailbox register, letting the hardware know the last status=20 > block update > > handled. > > If necessary the hardware will generate a new interrupt and=20 > start the > > process over > > again. > >=20 > > This entire process should be included in the Linux driver,=20 > I don't see > > it being > > used in the bge driver (bge_intr()). > >=20 > > Dave > >=20 >=20 > Could you please answer few questions? >=20 > 1) I've found status tag is returned in status block even if=20 > bit 9 of Misc. > Host Control Register is not set, is it ok? Which controller are you using? This bit is reserved on the 5700 (which didn't support tagged status mode) but all other controllers should support it and all of the Broadcom drivers will always enable it. >=20 > 2) Status tag is returned in bits 0-7 of status tag field of=20 > status block, > as long as i know it should be returned in bits 31-24, is it ok? Not sure what you mean by this. If you're seeing it in bits 31-24 of the status block then there may be an endian issue on your system. Check that byte/word swapping is set correctly. >=20 > 3) If i try to return processed tag (at the end of ISR) in=20 > Mailbox 0 register: > CSR_WRITE_4(sc, BGE_MBX_IRQ0_LO, status_tag << 24); > it would lead to disabled interrupts. > I've thought this should not happen cause in_isr bits=20 > (0-23) are cleared. Writing a non-zero value to bits 23:0 will cause the interrupt to be disabled: CSR_WRITE_4(sc, BGE_MBX_IRQ0_LO, 1); Writing all zeros to bits 23:0 will enable interrupts. CSR_WRITE_4(sc, BGE_MBX_IRQ0_LO, status_tag << 24); The tag value written to bits 31:24 does not affect the interrupt state. >=20 > --=20 > Oleg. >=20 >=20 >=20 From owner-freebsd-net@FreeBSD.ORG Thu Aug 24 01:04:28 2006 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6FC3016A4DD; Thu, 24 Aug 2006 01:04:28 +0000 (UTC) (envelope-from oleg@lath.rinet.ru) Received: from lath.rinet.ru (lath.rinet.ru [195.54.192.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id DD99843D49; Thu, 24 Aug 2006 01:04:27 +0000 (GMT) (envelope-from oleg@lath.rinet.ru) Received: from lath.rinet.ru (localhost [127.0.0.1]) by lath.rinet.ru (8.13.6/8.13.6) with ESMTP id k7O14NfZ027821 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Aug 2006 05:04:23 +0400 (MSD) (envelope-from oleg@lath.rinet.ru) Received: (from oleg@localhost) by lath.rinet.ru (8.13.6/8.13.6/Submit) id k7O14N0t027820; Thu, 24 Aug 2006 05:04:23 +0400 (MSD) (envelope-from oleg) Date: Thu, 24 Aug 2006 05:04:23 +0400 From: Oleg Bulyzhin To: David Christensen Message-ID: <20060824010423.GA27699@lath.rinet.ru> References: <20060823235632.GA25876@lath.rinet.ru> <09BFF2FA5EAB4A45B6655E151BBDD90301D4312A@NT-IRVA-0750.brcm.ad.broadcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <09BFF2FA5EAB4A45B6655E151BBDD90301D4312A@NT-IRVA-0750.brcm.ad.broadcom.com> User-Agent: Mutt/1.5.11 Cc: brad@openbsd.org, Gleb Smirnoff , net@FreeBSD.org Subject: Re: bge(4) one packet wedge 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, 24 Aug 2006 01:04:28 -0000 On Wed, Aug 23, 2006 at 05:54:24PM -0700, David Christensen wrote: > > On Wed, Aug 23, 2006 at 12:53:49PM -0700, David Christensen wrote: > > > This "lost interrupt" type of problem is addressed by the use of the > > > status_tag > > > field in the status block. (Listed as bge_rsvd0 in the > > bge_status_block > > > structure). > > > Everytime the status block is updated a new tag value is > > written to the > > > status block. > > > When the ISR starts the driver should record the status_tag > > value. At > > > the end > > > of the ISR, the driver should compare the current > > status_tag value is > > > the status > > > block with the value recorded on entry to the ISR. If the > > values are > > > the same > > > then no additional status block updates have occurred so > > there shouldn't > > > be > > > any packets hanging around. If the values are different > > then additional > > > packets > > > or completions are waiting around so the ISR should loop > > around again. > > > At the > > > end of the ISR the driver will write the status_tag value it last > > > handled to a > > > mailbox register, letting the hardware know the last status > > block update > > > handled. > > > If necessary the hardware will generate a new interrupt and > > start the > > > process over > > > again. > > > > > > This entire process should be included in the Linux driver, > > I don't see > > > it being > > > used in the bge driver (bge_intr()). > > > > > > Dave > > > > > > > Could you please answer few questions? > > > > 1) I've found status tag is returned in status block even if > > bit 9 of Misc. > > Host Control Register is not set, is it ok? > > Which controller are you using? This bit is reserved on the 5700 > (which didn't support tagged status mode) but all other controllers > should support it and all of the Broadcom drivers will always > enable it. I tested it on bcm5701 & bcm5721 > > > > > 2) Status tag is returned in bits 0-7 of status tag field of > > status block, > > as long as i know it should be returned in bits 31-24, is it ok? > > Not sure what you mean by this. If you're seeing it in bits 31-24 > of the status block then there may be an endian issue on your system. > Check that byte/word swapping is set correctly. > > > > > 3) If i try to return processed tag (at the end of ISR) in > > Mailbox 0 register: > > CSR_WRITE_4(sc, BGE_MBX_IRQ0_LO, status_tag << 24); > > it would lead to disabled interrupts. > > I've thought this should not happen cause in_isr bits > > (0-23) are cleared. > > Writing a non-zero value to bits 23:0 will cause the interrupt to > be disabled: > > CSR_WRITE_4(sc, BGE_MBX_IRQ0_LO, 1); > > Writing all zeros to bits 23:0 will enable interrupts. > > CSR_WRITE_4(sc, BGE_MBX_IRQ0_LO, status_tag << 24); > > The tag value written to bits 31:24 does not affect the interrupt > state. Yes, this is i'm talking about: CSR_WRITE_4(sc, BGE_MBX_IRQ0_LO, 0x01000000) would lead to _disabled_ interrupts. Tested on bcm5701 & bcm5721. P.S. bcm5705 does not support tagged status mode, am i right? -- Oleg. From owner-freebsd-net@FreeBSD.ORG Thu Aug 24 01:21:43 2006 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4F3F216A4DD; Thu, 24 Aug 2006 01:21:43 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id C525043D45; Thu, 24 Aug 2006 01:21:42 +0000 (GMT) (envelope-from davidch@broadcom.com) Received: from 10.10.64.154 by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Wed, 23 Aug 2006 18:21:31 -0700 X-Server-Uuid: D9EB6F12-1469-4C1C-87A2-5E4C0D6F9D06 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id CA3DF2AF; Wed, 23 Aug 2006 18:21:30 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 9FE552AE; Wed, 23 Aug 2006 18:21:30 -0700 (PDT) Received: from mail-irva-12.broadcom.com (mail-irva-12.broadcom.com [10.10.64.146]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id EDM58530; Wed, 23 Aug 2006 18:21:30 -0700 (PDT) Received: from NT-IRVA-0750.brcm.ad.broadcom.com (nt-irva-0750 [10.8.194.64]) by mail-irva-12.broadcom.com (Postfix) with ESMTP id 14A3E69CA4; Wed, 23 Aug 2006 18:21:30 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 23 Aug 2006 18:21:28 -0700 Message-ID: <09BFF2FA5EAB4A45B6655E151BBDD90301D43136@NT-IRVA-0750.brcm.ad.broadcom.com> In-Reply-To: <20060824010423.GA27699@lath.rinet.ru> Thread-Topic: bge(4) one packet wedge Thread-Index: AcbHGUkhGgRNirAnQkGGDEjM78XVwwAAVCWQ From: "David Christensen" To: "Oleg Bulyzhin" X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006082313; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413031303230332E34344543464530422E303030432D412D; ENG=IBF; TS=20060824012135; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006082313_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 68F220913881580588-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: brad@openbsd.org, Gleb Smirnoff , net@FreeBSD.org Subject: RE: bge(4) one packet wedge 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, 24 Aug 2006 01:21:43 -0000 > > > Could you please answer few questions? > > >=20 > > > 1) I've found status tag is returned in status block even if=20 > > > bit 9 of Misc. > > > Host Control Register is not set, is it ok? > >=20 > > Which controller are you using? This bit is reserved on the 5700 > > (which didn't support tagged status mode) but all other controllers > > should support it and all of the Broadcom drivers will always > > enable it. >=20 > I tested it on bcm5701 & bcm5721 >=20 > >=20 > > >=20 > > > 2) Status tag is returned in bits 0-7 of status tag field of=20 > > > status block, > > > as long as i know it should be returned in bits 31-24,=20 > is it ok? > >=20 > > Not sure what you mean by this. If you're seeing it in bits 31-24 > > of the status block then there may be an endian issue on=20 > your system. > > Check that byte/word swapping is set correctly. > >=20 > > >=20 > > > 3) If i try to return processed tag (at the end of ISR) in=20 > > > Mailbox 0 register: > > > CSR_WRITE_4(sc, BGE_MBX_IRQ0_LO, status_tag << 24); > > > it would lead to disabled interrupts. > > > I've thought this should not happen cause in_isr bits=20 > > > (0-23) are cleared. > >=20 > > Writing a non-zero value to bits 23:0 will cause the interrupt to > > be disabled: > >=20 > > CSR_WRITE_4(sc, BGE_MBX_IRQ0_LO, 1); > >=20 > > Writing all zeros to bits 23:0 will enable interrupts. > >=20 > > CSR_WRITE_4(sc, BGE_MBX_IRQ0_LO, status_tag << 24); > >=20 > > The tag value written to bits 31:24 does not affect the interrupt > > state. >=20 > Yes, this is i'm talking about: > CSR_WRITE_4(sc, BGE_MBX_IRQ0_LO, 0x01000000) would lead to _disabled_ > interrupts. > Tested on bcm5701 & bcm5721. Here's how it's done in Linux: static void tg3_disable_ints(struct tg3 *tp) { tw32(TG3PCI_MISC_HOST_CTRL, (tp->misc_host_ctrl | MISC_HOST_CTRL_MASK_PCI_INT)); tw32_mailbox_f(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW, 0x00000001); } static void tg3_enable_ints(struct tg3 *tp) { tp->irq_sync =3D 0; wmb(); tw32(TG3PCI_MISC_HOST_CTRL, (tp->misc_host_ctrl & ~MISC_HOST_CTRL_MASK_PCI_INT)); tw32_mailbox_f(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW, (tp->last_tag << 24)); if (tp->tg3_flags2 & TG3_FLG2_1SHOT_MSI) tw32_mailbox_f(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW, (tp->last_tag << 24)); tg3_cond_int(tp); } >=20 > P.S. bcm5705 does not support tagged status mode, am i right? No, the 5705 should support tagged status mode, only the 5788 doesn't support it. The 5705 and 5788 are very closely related though. > --=20 > Oleg. From owner-freebsd-net@FreeBSD.ORG Thu Aug 24 01:35:40 2006 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E139016A4DA; Thu, 24 Aug 2006 01:35:40 +0000 (UTC) (envelope-from oleg@lath.rinet.ru) Received: from lath.rinet.ru (lath.rinet.ru [195.54.192.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D89743D49; Thu, 24 Aug 2006 01:35:39 +0000 (GMT) (envelope-from oleg@lath.rinet.ru) Received: from lath.rinet.ru (localhost [127.0.0.1]) by lath.rinet.ru (8.13.6/8.13.6) with ESMTP id k7O1Zad4028168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Aug 2006 05:35:36 +0400 (MSD) (envelope-from oleg@lath.rinet.ru) Received: (from oleg@localhost) by lath.rinet.ru (8.13.6/8.13.6/Submit) id k7O1ZZ40028167; Thu, 24 Aug 2006 05:35:35 +0400 (MSD) (envelope-from oleg) Date: Thu, 24 Aug 2006 05:35:35 +0400 From: Oleg Bulyzhin To: David Christensen Message-ID: <20060824013535.GD27699@lath.rinet.ru> References: <20060824010423.GA27699@lath.rinet.ru> <09BFF2FA5EAB4A45B6655E151BBDD90301D43136@NT-IRVA-0750.brcm.ad.broadcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <09BFF2FA5EAB4A45B6655E151BBDD90301D43136@NT-IRVA-0750.brcm.ad.broadcom.com> User-Agent: Mutt/1.5.11 Cc: brad@openbsd.org, Gleb Smirnoff , net@FreeBSD.org Subject: Re: bge(4) one packet wedge 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, 24 Aug 2006 01:35:41 -0000 On Wed, Aug 23, 2006 at 06:21:28PM -0700, David Christensen wrote: > Here's how it's done in Linux: > > static void tg3_disable_ints(struct tg3 *tp) > { > tw32(TG3PCI_MISC_HOST_CTRL, > (tp->misc_host_ctrl | MISC_HOST_CTRL_MASK_PCI_INT)); > tw32_mailbox_f(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW, > 0x00000001); > } > > static void tg3_enable_ints(struct tg3 *tp) > { > tp->irq_sync = 0; > wmb(); > > tw32(TG3PCI_MISC_HOST_CTRL, > (tp->misc_host_ctrl & ~MISC_HOST_CTRL_MASK_PCI_INT)); > tw32_mailbox_f(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW, > (tp->last_tag << 24)); > if (tp->tg3_flags2 & TG3_FLG2_1SHOT_MSI) > tw32_mailbox_f(MAILBOX_INTERRUPT_0 + TG3_64BIT_REG_LOW, > (tp->last_tag << 24)); > tg3_cond_int(tp); > } > > > > > P.S. bcm5705 does not support tagged status mode, am i right? > > No, the 5705 should support tagged status mode, only the 5788 doesn't > support it. The 5705 and 5788 are very closely related though. > Thank you. I'll look what's wrong with my interrupt handler. -- Oleg. From owner-freebsd-net@FreeBSD.ORG Thu Aug 24 01:47:49 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A26CC16A4E9 for ; Thu, 24 Aug 2006 01:47:49 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7B06643D70 for ; Thu, 24 Aug 2006 01:47:38 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: by py-out-1112.google.com with SMTP id o67so437494pye for ; Wed, 23 Aug 2006 18:47:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=pFcn0S47HOG9o2GaCD+K0Alc3TdtFr55kMgjjjBVjvGpVORaMnfSQTylsnn713MT02G0atypbo+bonOiS4gdK5BlB8+2zXmus7SoYixwkVknEMEh56tCZd+p4aYCdz2rXGuelzc9086Vfa0OwLhyNxDdkD1S5nH3e02qTVopqaE= Received: by 10.35.11.15 with SMTP id o15mr1702661pyi; Wed, 23 Aug 2006 18:47:38 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.gmail.com with ESMTP id 15sm2024789nzp.2006.08.23.18.47.35; Wed, 23 Aug 2006 18:47:37 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id k7O1ljAv023191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Aug 2006 10:47:45 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id k7O1lhmw023190; Thu, 24 Aug 2006 10:47:43 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Thu, 24 Aug 2006 10:47:43 +0900 From: Pyun YongHyeon To: David Christensen Message-ID: <20060824014743.GF22634@cdnetworks.co.kr> References: <20060823161649.GE76666@cell.sick.ru> <09BFF2FA5EAB4A45B6655E151BBDD90301D43002@NT-IRVA-0750.brcm.ad.broadcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <09BFF2FA5EAB4A45B6655E151BBDD90301D43002@NT-IRVA-0750.brcm.ad.broadcom.com> User-Agent: Mutt/1.4.2.1i Cc: brad@openbsd.org, Gleb Smirnoff , oleg@FreeBSD.org, net@FreeBSD.org Subject: Re: bge(4) one packet wedge X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2006 01:47:49 -0000 On Wed, Aug 23, 2006 at 12:53:49PM -0700, David Christensen wrote: > This "lost interrupt" type of problem is addressed by the use of the > status_tag > field in the status block. (Listed as bge_rsvd0 in the bge_status_block > structure). > Everytime the status block is updated a new tag value is written to the > status block. > When the ISR starts the driver should record the status_tag value. At > the end > of the ISR, the driver should compare the current status_tag value is > the status > block with the value recorded on entry to the ISR. If the values are > the same > then no additional status block updates have occurred so there shouldn't > be > any packets hanging around. If the values are different then additional > packets > or completions are waiting around so the ISR should loop around again. > At the > end of the ISR the driver will write the status_tag value it last > handled to a > mailbox register, letting the hardware know the last status block update > handled. > If necessary the hardware will generate a new interrupt and start the > process over > again. > > This entire process should be included in the Linux driver, I don't see > it being > used in the bge driver (bge_intr()). > Hi, I have a question too. How we know generated interrupt is ours? It seems that status block could be updated before/after generation of an interrupt. If the interrupt is shared with other devices what is correct way to know the origion of the interrupt? -- Regards, Pyun YongHyeon From owner-freebsd-net@FreeBSD.ORG Thu Aug 24 04:21:21 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6B18616A4DD for ; Thu, 24 Aug 2006 04:21:21 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from koef.zs64.net (koef.zs64.net [213.238.47.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC53D43D53 for ; Thu, 24 Aug 2006 04:21:20 +0000 (GMT) (envelope-from stb@lassitu.de) Received: (from stb@koef.zs64.net) (authenticated) by koef.zs64.net (8.13.8/8.13.7) with ESMTP id k7O4L7DD083959 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Thu, 24 Aug 2006 06:21:18 +0200 (CEST) (envelope-from stb@lassitu.de) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: freebsd-net@freebsd.org From: Stefan Bethke Date: Thu, 24 Aug 2006 06:21:07 +0200 X-Mailer: Apple Mail (2.752.2) Subject: ppp(8) / ng_pppoe: choked output queue? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2006 04:21:21 -0000 Hi, just found my router being unable to reestablish the PPPoE connection this morning. This had been going on for about four hours before I restarted ppp. Any ideas what would cause the output queue to choke, why it would report Already in NETWORK phase, why the output queue is choking, and why ppp can't successfully clear it? Aug 24 05:52:32 diesel ppp[330]: Phase: deflink: Connected! Aug 24 05:52:32 diesel ppp[330]: Phase: deflink: opening -> dial Aug 24 05:52:32 diesel ppp[330]: Phase: deflink: dial -> carrier Aug 24 05:52:33 diesel ppp[330]: Phase: Received NGM_PPPOE_ACNAME (hook "HN-XDSL") Aug 24 05:52:33 diesel ppp[330]: Phase: Received NGM_PPPOE_SESSIONID Aug 24 05:52:33 diesel ppp[330]: Phase: Received NGM_PPPOE_SUCCESS Aug 24 05:52:33 diesel ppp[330]: Phase: deflink: carrier -> login Aug 24 05:52:33 diesel ppp[330]: Phase: deflink: login -> lcp Aug 24 05:52:34 diesel ppp[330]: Phase: deflink: his = CHAP 0x05, mine = none Aug 24 05:52:34 diesel ppp[330]: Phase: Chap Input: CHALLENGE (24 bytes from BRUN-0176-03-11) Aug 24 05:52:34 diesel ppp[330]: Phase: Chap Output: RESPONSE (04022758623) Aug 24 05:52:34 diesel ppp[330]: Phase: Chap Input: SUCCESS Aug 24 05:52:34 diesel ppp[330]: Phase: deflink: Already in NETWORK phase Aug 24 05:52:34 diesel ppp[330]: Phase: deflink: lcp -> open Aug 24 05:52:39 diesel ppp[330]: Phase: Clearing choked output queue Aug 24 05:54:34 diesel ppp[330]: Phase: deflink: open -> lcp Aug 24 05:54:34 diesel ppp[330]: Phase: Received NGM_PPPOE_CLOSE Aug 24 05:54:34 diesel ppp[330]: Phase: deflink: Device disconnected Aug 24 05:54:34 diesel ppp[330]: Phase: deflink: Disconnected! Aug 24 05:54:34 diesel ppp[330]: Phase: deflink: lcp -> logout Aug 24 05:54:34 diesel ppp[330]: Phase: deflink: Disconnected! Aug 24 05:54:34 diesel ppp[330]: Phase: deflink: logout -> hangup Aug 24 05:54:34 diesel ppp[330]: Phase: deflink: Connect time: 122 secs: 841 octets in, 533 octets out Aug 24 05:54:34 diesel ppp[330]: Phase: deflink: 985248 packets in, 622067 packets out Aug 24 05:54:34 diesel ppp[330]: Phase: total 11 bytes/sec, peak 61 bytes/sec on Thu Aug 24 05:52:35 2006 Aug 24 05:54:34 diesel ppp[330]: Phase: deflink: hangup -> opening Aug 24 05:54:34 diesel ppp[330]: Phase: deflink: Enter pause (15) for redialing. Aug 24 05:54:39 diesel ppp[330]: Phase: Clearing choked output queue Here's the successful connection from by restarting ppp: Aug 24 06:11:08 diesel ppp[91689]: Phase: Using interface: tun0 Aug 24 06:11:08 diesel ppp[91689]: Phase: deflink: Created in closed state Aug 24 06:11:08 diesel ppp[91690]: Phase: PPP Started (ddial mode). Aug 24 06:11:08 diesel ppp[91690]: Phase: bundle: Establish Aug 24 06:11:08 diesel ppp[91690]: Phase: deflink: closed -> opening Aug 24 06:11:08 diesel ppp[91690]: Phase: deflink: Connected! Aug 24 06:11:08 diesel ppp[91690]: Phase: deflink: opening -> dial Aug 24 06:11:08 diesel ppp[91690]: Phase: deflink: dial -> carrier Aug 24 06:11:09 diesel ppp[91690]: Phase: Received NGM_PPPOE_ACNAME (hook "HN-XDSL") Aug 24 06:11:09 diesel ppp[91690]: Phase: Received NGM_PPPOE_SESSIONID Aug 24 06:11:09 diesel ppp[91690]: Phase: Received NGM_PPPOE_SUCCESS Aug 24 06:11:09 diesel ppp[91690]: Phase: deflink: carrier -> login Aug 24 06:11:09 diesel ppp[91690]: Phase: deflink: login -> lcp Aug 24 06:11:10 diesel ppp[91690]: Phase: bundle: Authenticate Aug 24 06:11:10 diesel ppp[91690]: Phase: deflink: his = CHAP 0x05, mine = none Aug 24 06:11:10 diesel ppp[91690]: Phase: Chap Input: CHALLENGE (17 bytes from BRUN-0176-03-11) Aug 24 06:11:10 diesel ppp[91690]: Phase: Chap Output: RESPONSE (04022758623) Aug 24 06:11:11 diesel ppp[91690]: Phase: Chap Input: SUCCESS Aug 24 06:11:11 diesel ppp[91690]: Phase: deflink: lcp -> open Aug 24 06:11:11 diesel ppp[91690]: Phase: bundle: Network Stefan -- Stefan Bethke Fon +49 170 346 0140 From owner-freebsd-net@FreeBSD.ORG Thu Aug 24 04:31:46 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3B63116A4DA for ; Thu, 24 Aug 2006 04:31:46 +0000 (UTC) (envelope-from prvs=julian=3845287f1@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id EAE7043D45 for ; Thu, 24 Aug 2006 04:31:42 +0000 (GMT) (envelope-from prvs=julian=3845287f1@elischer.org) Received: from unknown (HELO [192.168.2.3]) ([10.251.60.33]) by a50.ironport.com with ESMTP; 23 Aug 2006 21:31:37 -0700 Message-ID: <44ED2BA8.60408@elischer.org> Date: Wed, 23 Aug 2006 21:31:36 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stefan Bethke References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: ppp(8) / ng_pppoe: choked output queue? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2006 04:31:46 -0000 Stefan Bethke wrote: > Hi, > > just found my router being unable to reestablish the PPPoE connection > this morning. This had been going on for about four hours before I > restarted ppp. Any ideas what would cause the output queue to choke, > why it would report Already in NETWORK phase, why the output queue is > choking, and why ppp can't successfully clear it? > > Aug 24 05:52:32 diesel ppp[330]: Phase: deflink: Connected! > Aug 24 05:52:32 diesel ppp[330]: Phase: deflink: opening -> dial > Aug 24 05:52:32 diesel ppp[330]: Phase: deflink: dial -> carrier > Aug 24 05:52:33 diesel ppp[330]: Phase: Received NGM_PPPOE_ACNAME > (hook "HN-XDSL") > Aug 24 05:52:33 diesel ppp[330]: Phase: Received NGM_PPPOE_SESSIONID > Aug 24 05:52:33 diesel ppp[330]: Phase: Received NGM_PPPOE_SUCCESS > Aug 24 05:52:33 diesel ppp[330]: Phase: deflink: carrier -> login > Aug 24 05:52:33 diesel ppp[330]: Phase: deflink: login -> lcp > Aug 24 05:52:34 diesel ppp[330]: Phase: deflink: his = CHAP 0x05, > mine = none > Aug 24 05:52:34 diesel ppp[330]: Phase: Chap Input: CHALLENGE (24 > bytes from BRUN-0176-03-11) > Aug 24 05:52:34 diesel ppp[330]: Phase: Chap Output: RESPONSE > (04022758623) > Aug 24 05:52:34 diesel ppp[330]: Phase: Chap Input: SUCCESS > Aug 24 05:52:34 diesel ppp[330]: Phase: deflink: Already in NETWORK > phase > Aug 24 05:52:34 diesel ppp[330]: Phase: deflink: lcp -> open > Aug 24 05:52:39 diesel ppp[330]: Phase: Clearing choked output queue > Aug 24 05:54:34 diesel ppp[330]: Phase: deflink: open -> lcp > Aug 24 05:54:34 diesel ppp[330]: Phase: Received NGM_PPPOE_CLOSE > Aug 24 05:54:34 diesel ppp[330]: Phase: deflink: Device disconnected > Aug 24 05:54:34 diesel ppp[330]: Phase: deflink: Disconnected! > Aug 24 05:54:34 diesel ppp[330]: Phase: deflink: lcp -> logout > Aug 24 05:54:34 diesel ppp[330]: Phase: deflink: Disconnected! > Aug 24 05:54:34 diesel ppp[330]: Phase: deflink: logout -> hangup > Aug 24 05:54:34 diesel ppp[330]: Phase: deflink: Connect time: 122 > secs: 841 octets in, 533 octets out > Aug 24 05:54:34 diesel ppp[330]: Phase: deflink: 985248 packets in, > 622067 packets out > Aug 24 05:54:34 diesel ppp[330]: Phase: total 11 bytes/sec, peak 61 > bytes/sec on Thu Aug 24 05:52:35 2006 > Aug 24 05:54:34 diesel ppp[330]: Phase: deflink: hangup -> opening > Aug 24 05:54:34 diesel ppp[330]: Phase: deflink: Enter pause (15) for > redialing. > Aug 24 05:54:39 diesel ppp[330]: Phase: Clearing choked output queue > > Here's the successful connection from by restarting ppp: > Aug 24 06:11:08 diesel ppp[91689]: Phase: Using interface: tun0 > Aug 24 06:11:08 diesel ppp[91689]: Phase: deflink: Created in closed > state > Aug 24 06:11:08 diesel ppp[91690]: Phase: PPP Started (ddial mode). > Aug 24 06:11:08 diesel ppp[91690]: Phase: bundle: Establish > Aug 24 06:11:08 diesel ppp[91690]: Phase: deflink: closed -> opening > Aug 24 06:11:08 diesel ppp[91690]: Phase: deflink: Connected! > Aug 24 06:11:08 diesel ppp[91690]: Phase: deflink: opening -> dial > Aug 24 06:11:08 diesel ppp[91690]: Phase: deflink: dial -> carrier > Aug 24 06:11:09 diesel ppp[91690]: Phase: Received NGM_PPPOE_ACNAME > (hook "HN-XDSL") > Aug 24 06:11:09 diesel ppp[91690]: Phase: Received NGM_PPPOE_SESSIONID > Aug 24 06:11:09 diesel ppp[91690]: Phase: Received NGM_PPPOE_SUCCESS > Aug 24 06:11:09 diesel ppp[91690]: Phase: deflink: carrier -> login > Aug 24 06:11:09 diesel ppp[91690]: Phase: deflink: login -> lcp > Aug 24 06:11:10 diesel ppp[91690]: Phase: bundle: Authenticate > Aug 24 06:11:10 diesel ppp[91690]: Phase: deflink: his = CHAP 0x05, > mine = none > Aug 24 06:11:10 diesel ppp[91690]: Phase: Chap Input: CHALLENGE (17 > bytes from BRUN-0176-03-11) > Aug 24 06:11:10 diesel ppp[91690]: Phase: Chap Output: RESPONSE > (04022758623) > Aug 24 06:11:11 diesel ppp[91690]: Phase: Chap Input: SUCCESS > Aug 24 06:11:11 diesel ppp[91690]: Phase: deflink: lcp -> open > Aug 24 06:11:11 diesel ppp[91690]: Phase: bundle: Network > > > Stefan > if it happens again, get a tcpdump of your ethernet interface.. (the one pppoe is using) From owner-freebsd-net@FreeBSD.ORG Thu Aug 24 05:40:45 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1941E16A524; Thu, 24 Aug 2006 05:40:45 +0000 (UTC) (envelope-from fli+freebsd-net@shapeshifter.se) Received: from mx1.h3q.net (manticore.shapeshifter.se [212.37.5.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7C0C343D46; Thu, 24 Aug 2006 05:40:43 +0000 (GMT) (envelope-from fli+freebsd-net@shapeshifter.se) Received: from localhost (localhost [127.0.0.1]) by mx1.h3q.net (Postfix) with ESMTP id 899061A78D; Thu, 24 Aug 2006 07:40:41 +0200 (CEST) Received: from mx1.h3q.net ([127.0.0.1]) by localhost (mx1.h3q.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23772-04; Thu, 24 Aug 2006 07:40:39 +0200 (CEST) Received: from [192.168.1.100] (217-208-33-252-o926.tbon.telia.com [217.208.33.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.h3q.net (Postfix) with ESMTP id B41121A751; Thu, 24 Aug 2006 07:40:38 +0200 (CEST) Message-ID: <44ED3BD1.3030206@shapeshifter.se> Date: Thu, 24 Aug 2006 07:40:33 +0200 From: Fredrik Lindberg User-Agent: Thunderbird 1.5.0.4 (X11/20060727) MIME-Version: 1.0 To: Pat Lashley References: <44EA1926.2000501@shapeshifter.se> <9C04919EE684029A410DE208@garrett.local> <44EAC40E.9000904@shapeshifter.se> <3E654CC0217F90E20FCD806E@garrett.local> <44EC90B7.6090908@shapeshifter.se> <44ECB0F2.9040300@FreeBSD.org> <20060823212110.GD27961@lor.one-eyed-alien.net> <20060823221835.GA28978@lor.one-eyed-alien.net> <23D2619F6BACE4E728178EE5@garrett.local> In-Reply-To: <23D2619F6BACE4E728178EE5@garrett.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at h3q.net Cc: freebsd-net@freebsd.org, Doug Barton Subject: Re: Zeroconfig and Multicast DNS 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, 24 Aug 2006 05:40:45 -0000 Pat Lashley wrote: > >> The one thing >> I'd be worried about is how the socket code handles connect() requests. >> My hope would be that it would pick the address that goes with the >> router to be used and thus the LLA would never be the source of a packet >> going to a non-LLA address in normal circumstances. > > The RFC is pretty explicit about the need to prefer non-LLA addresses. > We may need to put some explicit checks in the connect() code to enforce > that preference in the aliased case. The trick, of course, is to > recognize those cases where the LLA address must be used anyway. > > Hmmm. Interesting routing problem. Basically, we need to prefer a route > that doesn't use the LLA (unless the destination is in an LLA); but > still handle the edge cases like having the default route be through an > LLA-only-connected router. (Which MUST do NAT...) > > Um..wouldn't the routing code handle this? If you set a lla address and some other address on a interface like 192.168.0.2 or something and then a default route of 192.168.0.1, I would assume that an application without specific knowledge that tries to contact an external address would get 192.168.0.2 as the source address and that the packet is sent to 192.168.0.1. If you're in the situation that you need lla (no dhcp server available), you wouldn't know the default route right? And if you need to configure the default route manually it isn't really zeroconfig any longer. Fredrik Lindberg From owner-freebsd-net@FreeBSD.ORG Thu Aug 24 06:09:33 2006 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 71A1116A4DD; Thu, 24 Aug 2006 06:09:33 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7097D43D55; Thu, 24 Aug 2006 06:09:32 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.4/8.13.3) with ESMTP id k7O69NUc081374 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Aug 2006 10:09:23 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.4/8.13.1/Submit) id k7O69MN2081373; Thu, 24 Aug 2006 10:09:22 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 24 Aug 2006 10:09:22 +0400 From: Gleb Smirnoff To: David Christensen Message-ID: <20060824060922.GF76666@cell.sick.ru> References: <20060823161649.GE76666@cell.sick.ru> <09BFF2FA5EAB4A45B6655E151BBDD90301D43002@NT-IRVA-0750.brcm.ad.broadcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <09BFF2FA5EAB4A45B6655E151BBDD90301D43002@NT-IRVA-0750.brcm.ad.broadcom.com> User-Agent: Mutt/1.5.6i Cc: brad@openbsd.org, oleg@FreeBSD.org, net@FreeBSD.org Subject: Re: bge(4) one packet wedge 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, 24 Aug 2006 06:09:33 -0000 On Wed, Aug 23, 2006 at 12:53:49PM -0700, David Christensen wrote: D> This "lost interrupt" type of problem is addressed by the use of the D> status_tag D> field in the status block. (Listed as bge_rsvd0 in the bge_status_block D> structure). D> Everytime the status block is updated a new tag value is written to the D> status block. D> When the ISR starts the driver should record the status_tag value. At D> the end D> of the ISR, the driver should compare the current status_tag value is D> the status D> block with the value recorded on entry to the ISR. If the values are D> the same D> then no additional status block updates have occurred so there shouldn't D> be D> any packets hanging around. If the values are different then additional D> packets D> or completions are waiting around so the ISR should loop around again. D> At the D> end of the ISR the driver will write the status_tag value it last D> handled to a D> mailbox register, letting the hardware know the last status block update D> handled. D> If necessary the hardware will generate a new interrupt and start the D> process over D> again. D> D> This entire process should be included in the Linux driver, I don't see D> it being D> used in the bge driver (bge_intr()). True, this isn't done in FreeBSD driver. First I started to work on this, but just noticed that I am seeing this problem on 5700 chip, that is known not to support the status tag. What can be the problem for not updated status block in the 5700 case? -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Thu Aug 24 06:38:32 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 04A0816A4DD; Thu, 24 Aug 2006 06:38:32 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from gaia.nimnet.asn.au (nimbin.lnk.telstra.net [139.130.45.143]) by mx1.FreeBSD.org (Postfix) with ESMTP id A910543D45; Thu, 24 Aug 2006 06:38:29 +0000 (GMT) (envelope-from smithi@nimnet.asn.au) Received: from localhost (smithi@localhost) by gaia.nimnet.asn.au (8.8.8/8.8.8R1.4) with SMTP id QAA14631; Thu, 24 Aug 2006 16:38:05 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Thu, 24 Aug 2006 16:38:05 +1000 (EST) From: Ian Smith To: Pat Lashley In-Reply-To: <23D2619F6BACE4E728178EE5@garrett.local> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-net@freebsd.org, Doug Barton , Fredrik Lindberg Subject: Re: Zeroconfig and Multicast DNS 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, 24 Aug 2006 06:38:32 -0000 I've been watching this thread with great interest, having recently been introduced to the possibilities of OLSR (net/olsrd) for local (and beyond) P2P wi-mesh networks, and wondering if/how zeroconf fits in. Some refs: My discovery point, a great (online) book found from a review by Geoff Huston in the Internet Protocol Journal Vol 9 No 2, p44: Wireless Networking in the Developing World: http://wndw.net/ OLSR.ORG: http://www.olsr.org/ RFC: http://ietf.org/rfc/rfc3626.txt (basis, though olsrd extends this) Host addresses in such a MANET appear to require manual allocation so far, usually in RFC1918 ranges, but the notion of zeroconfig-joining such a network seems perhaps worthy of exploration? Am I way off base here, thinking some matchmaking might be useful? Cheers, Ian On Wed, 23 Aug 2006, Pat Lashley wrote: [..] > Hmmm. Interesting routing problem. Basically, we need to prefer a route that > doesn't use the LLA (unless the destination is in an LLA); but still handle the > edge cases like having the default route be through an LLA-only-connected > router. (Which MUST do NAT...) > We also need to keep an eye towards dynamic roaming. One scenario is a campus > composed of multiple Link Local zones and WiFi. As you move around the campus > with your (running) laptop, it will have to re-negotiate/defend its LLA; and > may need to obtain a different one. The address of the default router is also > likely to change as it moves from one zone to another. > Of course, in that scenario it doesn't matter whether you have any non-LLA IP > addresses; since you won't be using them. BUT if you add in a mix of non-LLA > addresses advertised as servers; the routing adjustments could become quite > interesting... > > Some of the problems raised by roaming scenaria need not be addressed > immediately; but we do need to keep them in mind during the design phase to > ensure that our solution to the basic LLA/mDNS issues doesn't make the roaming > issues even harder to handle. From owner-freebsd-net@FreeBSD.ORG Thu Aug 24 07:53:00 2006 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 85C1D16A4DD; Thu, 24 Aug 2006 07:53:00 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id A66F043D46; Thu, 24 Aug 2006 07:52:59 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.4/8.13.3) with ESMTP id k7O7qr02082036 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Aug 2006 11:52:54 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.4/8.13.1/Submit) id k7O7qr27082035; Thu, 24 Aug 2006 11:52:53 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 24 Aug 2006 11:52:53 +0400 From: Gleb Smirnoff To: David Christensen Message-ID: <20060824075253.GH76666@cell.sick.ru> References: <20060823161649.GE76666@cell.sick.ru> <09BFF2FA5EAB4A45B6655E151BBDD90301D43002@NT-IRVA-0750.brcm.ad.broadcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <09BFF2FA5EAB4A45B6655E151BBDD90301D43002@NT-IRVA-0750.brcm.ad.broadcom.com> User-Agent: Mutt/1.5.6i Cc: brad@openbsd.org, oleg@FreeBSD.org, net@FreeBSD.org Subject: Re: bge(4) one packet wedge 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, 24 Aug 2006 07:53:00 -0000 On Wed, Aug 23, 2006 at 12:53:49PM -0700, David Christensen wrote: D> This "lost interrupt" type of problem is addressed by the use of the D> status_tag D> field in the status block. (Listed as bge_rsvd0 in the bge_status_block D> structure). D> Everytime the status block is updated a new tag value is written to the D> status block. D> When the ISR starts the driver should record the status_tag value. At D> the end D> of the ISR, the driver should compare the current status_tag value is D> the status D> block with the value recorded on entry to the ISR. If the values are D> the same D> then no additional status block updates have occurred so there shouldn't D> be D> any packets hanging around. If the values are different then additional D> packets D> or completions are waiting around so the ISR should loop around again. D> At the D> end of the ISR the driver will write the status_tag value it last D> handled to a D> mailbox register, letting the hardware know the last status block update D> handled. D> If necessary the hardware will generate a new interrupt and start the D> process over D> again. D> D> This entire process should be included in the Linux driver, I don't see D> it being D> used in the bge driver (bge_intr()). In the Linux driver for the not tag capable controllers there is a following comment and code: /* In INTx mode, it is possible for the interrupt to arrive at * the CPU before the status block posted prior to the interrupt. * Reading the PCI State register will confirm whether the * interrupt is ours and will flush the status block. */ if ((sblk->status & SD_STATUS_UPDATED) || !(tr32(TG3PCI_PCISTATE) & PCISTATE_INT_NOT_ACTIVE)) { So, I tried to add (void)pci_read_config(sc->bge_dev, BGE_PCI_PCISTATE, 4) to the bge_intr(). Unfortunately, this didn't help. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Thu Aug 24 08:41:55 2006 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 99A2516A4DA; Thu, 24 Aug 2006 08:41:55 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id D7A3943D45; Thu, 24 Aug 2006 08:41:54 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.4/8.13.3) with ESMTP id k7O8foMW082372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Aug 2006 12:41:50 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.4/8.13.1/Submit) id k7O8fnpH082371; Thu, 24 Aug 2006 12:41:49 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 24 Aug 2006 12:41:49 +0400 From: Gleb Smirnoff To: David Christensen Message-ID: <20060824084149.GI76666@cell.sick.ru> References: <20060823161649.GE76666@cell.sick.ru> <09BFF2FA5EAB4A45B6655E151BBDD90301D43002@NT-IRVA-0750.brcm.ad.broadcom.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="NDin8bjvE/0mNLFQ" Content-Disposition: inline In-Reply-To: <09BFF2FA5EAB4A45B6655E151BBDD90301D43002@NT-IRVA-0750.brcm.ad.broadcom.com> User-Agent: Mutt/1.5.6i Cc: brad@openbsd.org, oleg@FreeBSD.org, net@FreeBSD.org Subject: Re: bge(4) one packet wedge 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, 24 Aug 2006 08:41:55 -0000 --NDin8bjvE/0mNLFQ Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Colleagues, pondering on the Linux driver more I have found that the only thing that fixed this problem on 5700 (no status tag support) is the hack in the local timer. So, I have prepared a hack that fixes my problem. Certainly, the performance of request-response test is awful, since chip wedges for a fraction of a second many times per minute. But at least, it doesn't wedge forever. I will continue working on the patch so that it will support the tagged controllers, but I need one to test. P.S. Looks like 5700 is not usable for my benchmarking in the request-response tests. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE --NDin8bjvE/0mNLFQ Content-Type: text/plain; charset=koi8-r Content-Disposition: attachment; filename="bge.status_block" Index: if_bge.c =================================================================== RCS file: /home/ncvs/src/sys/dev/bge/if_bge.c,v retrieving revision 1.139 diff -u -p -r1.139 if_bge.c --- if_bge.c 23 Aug 2006 11:32:54 -0000 1.139 +++ if_bge.c 24 Aug 2006 08:32:24 -0000 @@ -2705,6 +2719,7 @@ bge_intr(void *xsc) * Do the mandatory PCI flush as well as get the link status. */ statusword = CSR_READ_4(sc, BGE_MAC_STS) & BGE_MACSTAT_LINK_CHANGED; + sc->bge_ldata.bge_status_block->bge_status &= ~BGE_STATUS_UPDATED; /* Ack interrupt and stop others from occuring. */ CSR_WRITE_4(sc, BGE_MBX_IRQ0_LO, 1); @@ -2769,6 +2784,16 @@ bge_tick_locked(struct bge_softc *sc) } } + if (1) { /* Only for not-tagged IRQ status. */ + struct bge_status_block *sblock = sc->bge_ldata.bge_status_block; + + if (sblock->bge_status & BGE_STATUS_UPDATED) + BGE_SETBIT(sc, BGE_MISC_LOCAL_CTL, BGE_MLC_INTR_SET); + else + CSR_WRITE_4(sc, BGE_HCC_MODE, BGE_HCCMODE_ENABLE | + BGE_HCCMODE_COAL_NOW); + } + callout_reset(&sc->bge_stat_ch, hz, bge_tick, sc); } Index: if_bgereg.h =================================================================== RCS file: /home/ncvs/src/sys/dev/bge/if_bgereg.h,v retrieving revision 1.52 diff -u -p -r1.52 if_bgereg.h --- if_bgereg.h 23 Aug 2006 11:32:54 -0000 1.52 +++ if_bgereg.h 24 Aug 2006 08:21:10 -0000 @@ -1932,7 +1937,10 @@ struct bge_sts_idx { struct bge_status_block { uint32_t bge_status; - uint32_t bge_rsvd0; +#define BGE_STATUS_UPDATED 0x00000001 +#define BGE_STATUS_LINKEV 0x00000002 +#define BGE_STATUS_ERROR 0x00000004 + uint32_t bge_tag; #if BYTE_ORDER == LITTLE_ENDIAN uint16_t bge_rx_jumbo_cons_idx; uint16_t bge_rx_std_cons_idx; --NDin8bjvE/0mNLFQ-- From owner-freebsd-net@FreeBSD.ORG Thu Aug 24 10:41:51 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B92EA16A4E0; Thu, 24 Aug 2006 10:41:51 +0000 (UTC) (envelope-from fli+freebsd-net@shapeshifter.se) Received: from mx1.h3q.net (manticore.shapeshifter.se [212.37.5.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 143FF43D49; Thu, 24 Aug 2006 10:41:50 +0000 (GMT) (envelope-from fli+freebsd-net@shapeshifter.se) Received: from localhost (localhost [127.0.0.1]) by mx1.h3q.net (Postfix) with ESMTP id 84AD91A78D; Thu, 24 Aug 2006 12:41:48 +0200 (CEST) Received: from mx1.h3q.net ([127.0.0.1]) by localhost (mx1.h3q.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27260-05; Thu, 24 Aug 2006 12:41:47 +0200 (CEST) Received: from [192.168.1.100] (217-208-33-252-o926.tbon.telia.com [217.208.33.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.h3q.net (Postfix) with ESMTP id ED5B81A751; Thu, 24 Aug 2006 12:41:46 +0200 (CEST) Message-ID: <44ED8266.1060303@shapeshifter.se> Date: Thu, 24 Aug 2006 12:41:42 +0200 From: Fredrik Lindberg User-Agent: Thunderbird 1.5.0.4 (X11/20060727) MIME-Version: 1.0 To: Pat Lashley References: <44E9F991.7020309@shapeshifter.se> <44EA1926.2000501@shapeshifter.se> <9C04919EE684029A410DE208@garrett.local> <44EAC40E.9000904@shapeshifter.se> <3E654CC0217F90E20FCD806E@garrett.local> <44EC90B7.6090908@shapeshifter.se> <44ECB0F2.9040300@FreeBSD.org> <44ECBB61.9020808@shapeshifter.se> <5D7785ADC030FEBFB9A5E69D@garrett.local> In-Reply-To: <5D7785ADC030FEBFB9A5E69D@garrett.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at h3q.net Cc: freebsd-net@freebsd.org, Doug Barton Subject: Re: Zeroconfig and Multicast DNS 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, 24 Aug 2006 10:41:51 -0000 Pat Lashley wrote: >> As for mDNS/SD I think a generic responderd.conf/mdns.conf file should >> be available where you can configure "static" dns records. > > I would really rather see the service advertisement done in each > service's rc.d script. That has the advantage of not requiring the > mdns.conf file to be updated if the _enable knob is changed in > /etc/rc.conf. It also makes it easy to add a line to revoke the > advertisement in the rc.d script's 'stop' action. > > That said, static service advertisement via the mdns.conf file is useful > when advertising on behalf of of a system or embedded device that > doesn't have native mDNS support. (E.g., An older network-attached > printer.) > > The mdns.conf can also be used to advertise host records for hosts that > don't support mDNS. But again, it would be nice to have a config flag > that just says 'advertise everything in /etc/hosts' in addition to a way > to list individual entries. > I should probably explain better what I mean with this mdns.conf file, as I think there might be a misunderstanding about it. Let us for a second pretend that SD doesn't exist but mDNS does, mDNS without SD is still a very valuable protocol. The specs. says that each host should claim a unique host and also advertise a HINFO record, but this in my opinion a policy decision and should be left to the end user. A user might want to advertise 0, 1, 2 or many different unique records, and the main purpose of the mdns.conf file would be to provide a easy way to do so (without writing scripts that calls a cmd line utility). For example, a line in the mdns.conf might look like this $(hostname).local. A $(ifaddr) Might look cryptic but it just means announce a A record using my current hostname, append .local. and point it to whatever ip number that happens to be configured on my interface. These variables would be updated when things happen in the system (new ip address etc) Also, there is no technical limitation in the mDNS protocol that prevents it from working with other TLDs, so which TLD to use should also be up to the user (again a policy decision). Now we can get back to the reality where SD does exists. In addition to this mdns.conf we have the client API, using this client API a command line tool should be built that can insert and remove records (even those records configured using mdns.conf). Lets call this tool mdns for now (the name it doesn't matter, and isn't really the point). Programs announcing a service using SD would preferably call the mdns tool in their rc.d scripts to add/remove SD records. So I'm not voting for either side, I want 'em both and I definitely want a command line tool that rc.d-scripts can call to register records. > >> > 8. How should applications interact with this system? That includes >> stuff in >> > the FreeBSD base, and what APIs to publish for third party stuff. >> Are there >> > well established APIs that we should/must support? >> >> It's best to go with Apples API from mDNSResponder. > > It's not clear to me yet whether it is better to do that or to go with > the Avahi API; or to provide both. (I haven't actually looked at either; > so I don't know just how they differ.) If KDE and Gnome are using the Avahi API, then we really need to support it. But as you said we can probably implement both APIs as shim calls around our own API. >> > 10. How do users interact with this? Should there be a utility that >> allows >> > users to browse the network to see what services are available? >> As for mDNS and hostname in generic, users would interact with them just >> as with any other dns records or name. > > Right. Except for the additional bit of knowledge about the .local domain. > I've been thinking about this too. The NSS module would require a file similar to resolv.conf. It would contain a "white list" of allowed domains to resolv (local., 168.192.in-addr.arpa., 10.in-addr.arpa etc). But it could also contain a "search" directive so that if it receives a query for a name without a white listed TLD it appends for example ".local." to the name. It might be dangerous though as it could try to query for www.google.com.local., a solution to this would be do "blacklist" existing TLDs when a search is done or only to do a search if there are no dots in the name, I think the latter solution is the best Anyway, it would allow users to leave out the .local part when communicating which I think would be a nice feature. Fredrik Lindberg From owner-freebsd-net@FreeBSD.ORG Thu Aug 24 11:44:12 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D0B0016A4EE for ; Thu, 24 Aug 2006 11:44:12 +0000 (UTC) (envelope-from nvass@teledomenet.gr) Received: from matrix.teledomenet.gr (dns1.teledomenet.gr [213.142.128.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 37D2B43D46 for ; Thu, 24 Aug 2006 11:44:10 +0000 (GMT) (envelope-from nvass@teledomenet.gr) Received: from iris ([192.168.1.71]) by matrix.teledomenet.gr (8.12.10/8.12.10) with ESMTP id k7OBi8EY029146 for ; Thu, 24 Aug 2006 14:44:08 +0300 From: Nikos Vassiliadis To: net@freebsd.org Date: Thu, 24 Aug 2006 14:43:27 +0300 User-Agent: KMail/1.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200608241443.28431.nvass@teledomenet.gr> Cc: Subject: "high speed" tcp connections over pptp terminate unexpectedly 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, 24 Aug 2006 11:44:12 -0000 Hi all, I have a weird problem. It seems that tcp over pptp can not handle high speeds and connections terminate with no obvious reasons(at least to me). The tcpdump is from 6-STABLE, but I also have a 7-CURRENT machine I can test/try things. I have tried with fetch, konqueror and opera. The results are the same every time, the connection will reset eventually. When I switch my default gateway to a router everything works as expected. mpd doesn't print anything. Any thoughts, suggestions tcpdump readers? example ftp session nik:0:~$ fetch ftp://ftp.belnet.be/mirror/rsync.gentoo.org/gentoo/releases/x86/2006.0/livecd/livecd-i686-installer-2006.0.iso livecd-i686-installer-2006.0.iso 13% of 696 MB 492 kBps 20m52s fetch: transfer timed out fetch: livecd-i686-installer-2006.0.iso appears to be truncated: 100136960/730388480 bytes tcpdump where the reset happens 14:04:24.266162 IP 213.142.144.100.54456 > 193.190.198.20.38723: . ack 53514792 win 32832 14:04:24.270371 IP 193.190.198.20.38723 > 213.142.144.100.54456: P 53514792:53516160(1368) ack 1 win 49248 14:04:24.270546 IP 193.190.198.20.38723 > 213.142.144.100.54456: . 53516160:53517528(1368) ack 1 win 49248 14:04:24.270556 IP 213.142.144.100.54456 > 193.190.198.20.38723: . ack 53517528 win 32148 14:04:24.270775 IP 193.190.198.20.38723 > 213.142.144.100.54456: P 53517528:53518896(1368) ack 1 win 49248 14:04:24.270807 IP 213.142.144.100.54456 > 193.190.198.20.38723: . ack 53518896 win 32832 14:04:24.273327 IP 193.190.198.20.38723 > 213.142.144.100.54456: P 53518896:53520264(1368) ack 1 win 49248 14:04:24.273454 IP 193.190.198.20.38723 > 213.142.144.100.54456: . 53520264:53521632(1368) ack 1 win 49248 14:04:24.273465 IP 213.142.144.100.54456 > 193.190.198.20.38723: . ack 53521632 win 32148 14:04:24.273740 IP 193.190.198.20.38723 > 213.142.144.100.54456: P 53521632:53523000(1368) ack 1 win 49248 14:04:24.273775 IP 213.142.144.100.54456 > 193.190.198.20.38723: . ack 53523000 win 32832 14:04:24.274088 IP 213.142.144.100.54456 > 193.190.198.20.38723: R 1:1(0) ack 53523000 win 32832 14:04:24.275729 IP 193.190.198.20.38723 > 213.142.144.100.54456: P 53523000:53524368(1368) ack 1 win 49248 Thanks in advance, Nikos From owner-freebsd-net@FreeBSD.ORG Thu Aug 24 12:45:17 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7A4C716A4EF; Thu, 24 Aug 2006 12:45:17 +0000 (UTC) (envelope-from patl@volant.org) Received: from smtp.volant.org (gate.volant.org [207.111.218.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 53C5D43D58; Thu, 24 Aug 2006 12:45:16 +0000 (GMT) (envelope-from patl@volant.org) Received: from adsl-065-081-071-131.sip.gnv.bellsouth.net ([65.81.71.131] helo=[192.168.1.121]) by smtp.volant.org with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34 (FreeBSD)) id 1GGEdM-000KXR-4E; Thu, 24 Aug 2006 05:48:35 -0700 Date: Thu, 24 Aug 2006 05:44:20 -0400 From: Pat Lashley To: Fredrik Lindberg Message-ID: In-Reply-To: <44ED3BD1.3030206@shapeshifter.se> References: <44EA1926.2000501@shapeshifter.se> <9C04919EE684029A410DE208@garrett.local> <44EAC40E.9000904@shapeshifter.se> <3E654CC0217F90E20FCD806E@garrett.local> <44EC90B7.6090908@shapeshifter.se> <44ECB0F2.9040300@FreeBSD.org> <20060823212110.GD27961@lor.one-eyed-alien.net> <20060823221835.GA28978@lor.one-eyed-alien.net> <23D2619F6BACE4E728178EE5@garrett.local> <44ED3BD1.3030206@shapeshifter.se> X-Mailer: Mulberry/4.0.0 (Mac OS X) MIME-Version: 1.0 X-Scan-Signature: 9549dfdcd63b77beba3973726fde716993f503b7 X-Spam-User: nobody X-Spam-Score: -2.5 (--) X-Spam-Score-Int: -24 X-Spam-Report: This mail has matched the spam-filter tests listed below. See http://spamassassin.org/tag/ for details about the specific tests reported. In general, the higher the number of total points, the more likely that it actually is spam. (The 'required' number of points listed below is the arbitrary number above which the message is normally considered spam.) Content analysis details: (-2.5 points total, 5.0 required) 0.1 HTML_MESSAGE BODY: HTML included in message 0.1 HTML_FONTCOLOR_RED BODY: HTML font color is red -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.4 DATE_IN_PAST_03_06 Date: is 3 to 6 hours before Received: date 1.8 AWL AWL: Auto-whitelist adjustment Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, Doug Barton Subject: Re: Zeroconfig and Multicast DNS 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, 24 Aug 2006 12:45:17 -0000 > Um..wouldn't the routing code handle this? > If you set a lla address and some other address on a interface like 192.168.0.2 > or something and then a default route of 192.168.0.1, I > would assume that an application without specific knowledge that tries > to contact an external address would get 192.168.0.2 as the source > address and that the packet is sent to 192.168.0.1. It should handle it; but I'd still want someone to check out various edge conditions and pathological cases. > If you're in the situation that you need lla (no dhcp server available), The presence or absence of a DHCP server is not a good indicator of the need or desire for LLA and/or mDNS. It is quite possible that the system is in a mixed environment where there are some systems which are LLA/mDNS only, others which are DHCP/static/unicast DNS only, and others which handle both. > you wouldn't know the default route right? I believe that there is a way to announce routing service via mDNS-SD; but I don't know the details. (I would be astonished to discover that the people who developed the zeroconfig design left that bit out...) -Pat From owner-freebsd-net@FreeBSD.ORG Thu Aug 24 13:16:41 2006 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F389616A4DD; Thu, 24 Aug 2006 13:16:40 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A87643D62; Thu, 24 Aug 2006 13:16:38 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.4/8.13.3) with ESMTP id k7ODGWZL083978 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Aug 2006 17:16:33 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.4/8.13.1/Submit) id k7ODGWBj083977; Thu, 24 Aug 2006 17:16:32 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 24 Aug 2006 17:16:32 +0400 From: Gleb Smirnoff To: David Christensen Message-ID: <20060824131632.GN76666@FreeBSD.org> References: <20060823161649.GE76666@cell.sick.ru> <09BFF2FA5EAB4A45B6655E151BBDD90301D43002@NT-IRVA-0750.brcm.ad.broadcom.com> <20060824084149.GI76666@cell.sick.ru> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Fig2xvG2VGoz8o/s" Content-Disposition: inline In-Reply-To: <20060824084149.GI76666@cell.sick.ru> User-Agent: Mutt/1.5.6i Cc: brad@openbsd.org, oleg@FreeBSD.org, net@FreeBSD.org Subject: Re: bge(4) one packet wedge 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, 24 Aug 2006 13:16:41 -0000 --Fig2xvG2VGoz8o/s Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Here I have prepared a patch, that utilizes the tag in status block on the chips that can do this. It also moves some chip quirks startup code to a separate function. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE --Fig2xvG2VGoz8o/s Content-Type: text/plain; charset=koi8-r Content-Disposition: attachment; filename="bge.status_tag" Index: if_bge.c =================================================================== RCS file: /home/ncvs/src/sys/dev/bge/if_bge.c,v retrieving revision 1.139 diff -u -p -r1.139 if_bge.c --- if_bge.c 23 Aug 2006 11:32:54 -0000 1.139 +++ if_bge.c 24 Aug 2006 13:07:12 -0000 @@ -978,7 +978,7 @@ bge_chipinit(struct bge_softc *sc) int i; /* Set endian type before we access any non-PCI registers. */ - pci_write_config(sc->bge_dev, BGE_PCI_MISC_CTL, BGE_INIT, 4); + pci_write_config(sc->bge_dev, BGE_PCI_MISC_CTL, sc->bge_misc_ctl, 4); /* * Check the 'ROM failed' bit on the RX CPU to see if @@ -1982,6 +1982,70 @@ bge_dma_alloc(device_t dev) return (0); } +static void +bge_recognize(struct bge_softc *sc) +{ + device_t dev = sc->bge_dev; + uint32_t misccfg; + + /* Save ASIC rev. */ + sc->bge_chipid = + pci_read_config(dev, BGE_PCI_MISC_CTL, 4) & + BGE_PCIMISCCTL_ASICREV; + sc->bge_asicrev = BGE_ASICREV(sc->bge_chipid); + sc->bge_chiprev = BGE_CHIPREV(sc->bge_chipid); + + sc->bge_misc_ctl = (BGE_HIF_SWAP_OPTIONS | + BGE_PCIMISCCTL_CLEAR_INTA | + BGE_PCIMISCCTL_MASK_PCI_INTR | + BGE_PCIMISCCTL_INDIRECT_ACCESS); + sc->bge_hcc_mode = 0; + + /* + * XXX: Broadcom Linux driver. Not in specs or eratta. + * PCI-Express? + */ + if (BGE_IS_5705_OR_BEYOND(sc)) { + uint32_t v; + + v = pci_read_config(dev, BGE_PCI_MSI_CAPID, 4); + if (((v >> 8) & 0xff) == BGE_PCIE_CAPID_REG) { + v = pci_read_config(dev, BGE_PCIE_CAPID_REG, 4); + if ((v & 0xff) == BGE_PCIE_CAPID) + sc->bge_flags |= BGE_FLAG_PCIE; + } + } + + /* + * PCI-X? + */ + if ((pci_read_config(sc->bge_dev, BGE_PCI_PCISTATE, 4) & + BGE_PCISTATE_PCI_BUSMODE) == 0) + sc->bge_flags |= BGE_FLAG_PCIX; + + misccfg = CSR_READ_4(sc, BGE_MISC_CFG) & BGE_MISCCFG_BOARD_ID_MASK; + if (sc->bge_asicrev == BGE_ASICREV_BCM5705 && + (misccfg == BGE_MISCCFG_BOARD_ID_5788 || + misccfg == BGE_MISCCFG_BOARD_ID_5788M)) + sc->bge_flags |= BGE_FLAG_5788; + + if (sc->bge_chiprev != BGE_CHIPREV_5700_AX && + sc->bge_chiprev != BGE_CHIPREV_5700_BX) + sc->bge_hcc_mode |= BGE_STATBLKSZ_32BYTE; + + /* + * 5788 and 5700 does not support tagging the status block. + * This is workarounded in bge_tick_locked(). + */ + if (!(sc->bge_flags & BGE_FLAG_5788) && + sc->bge_asicrev != BGE_ASICREV_BCM5700) { + sc->bge_flags |= BGE_FLAG_STATUSTAG; + sc->bge_hcc_mode |= (BGE_HCCMODE_CLRTICK_RXBD | + BGE_HCCMODE_CLRTICK_TXBD); + sc->bge_misc_ctl |= BGE_PCIMISCCTL_TAGGED_STATUS; + } +} + static int bge_attach(device_t dev) { @@ -2027,35 +2091,8 @@ bge_attach(device_t dev) BGE_LOCK_INIT(sc, device_get_nameunit(dev)); - /* Save ASIC rev. */ - - sc->bge_chipid = - pci_read_config(dev, BGE_PCI_MISC_CTL, 4) & - BGE_PCIMISCCTL_ASICREV; - sc->bge_asicrev = BGE_ASICREV(sc->bge_chipid); - sc->bge_chiprev = BGE_CHIPREV(sc->bge_chipid); - - /* - * XXX: Broadcom Linux driver. Not in specs or eratta. - * PCI-Express? - */ - if (BGE_IS_5705_OR_BEYOND(sc)) { - uint32_t v; - - v = pci_read_config(dev, BGE_PCI_MSI_CAPID, 4); - if (((v >> 8) & 0xff) == BGE_PCIE_CAPID_REG) { - v = pci_read_config(dev, BGE_PCIE_CAPID_REG, 4); - if ((v & 0xff) == BGE_PCIE_CAPID) - sc->bge_flags |= BGE_FLAG_PCIE; - } - } - - /* - * PCI-X ? - */ - if ((pci_read_config(sc->bge_dev, BGE_PCI_PCISTATE, 4) & - BGE_PCISTATE_PCI_BUSMODE) == 0) - sc->bge_flags |= BGE_FLAG_PCIX; + /* Fill in bge_flags, recognize features/bugs.*/ + bge_recognize(sc); /* Try to reset the chip. */ bge_reset(sc); @@ -2684,16 +2721,13 @@ bge_poll(struct ifnet *ifp, enum poll_cm static void bge_intr(void *xsc) { - struct bge_softc *sc; - struct ifnet *ifp; + struct bge_softc *sc = xsc; + struct ifnet *ifp = sc->bge_ifp; + struct bge_status_block *sblock = sc->bge_ldata.bge_status_block; uint32_t statusword; - sc = xsc; - BGE_LOCK(sc); - ifp = sc->bge_ifp; - #ifdef DEVICE_POLLING if (ifp->if_capenable & IFCAP_POLLING) { BGE_UNLOCK(sc); @@ -2701,6 +2735,15 @@ bge_intr(void *xsc) } #endif + if ((((sc->bge_flags & BGE_FLAG_STATUSTAG) && + (sc->bge_last_tag == sblock->bge_tag)) || + !(sblock->bge_status & BGE_STATUS_UPDATED)) && + (pci_read_config(sc->bge_dev, BGE_PCI_PCISTATE, 4) & + BGE_PCISTATE_INTR_STATE)) { + /* Not our interrupt? */ + BGE_UNLOCK(sc); + return; + } /* * Do the mandatory PCI flush as well as get the link status. */ @@ -2729,7 +2772,13 @@ bge_intr(void *xsc) } /* Re-enable interrupts. */ - CSR_WRITE_4(sc, BGE_MBX_IRQ0_LO, 0); + if (sc->bge_flags & BGE_FLAG_STATUSTAG) { + sc->bge_last_tag = sblock->bge_tag; + CSR_WRITE_4(sc, BGE_MBX_IRQ0_LO, (sc->bge_last_tag << 24)); + } else { + sblock->bge_status &= ~BGE_STATUS_UPDATED; + CSR_WRITE_4(sc, BGE_MBX_IRQ0_LO, 0); + } if (ifp->if_drv_flags & IFF_DRV_RUNNING && !IFQ_DRV_IS_EMPTY(&ifp->if_snd)) @@ -2769,6 +2818,16 @@ bge_tick_locked(struct bge_softc *sc) } } + if (!(sc->bge_flags & BGE_FLAG_STATUSTAG)) { + struct bge_status_block *sblock = sc->bge_ldata.bge_status_block; + + if (sblock->bge_status & BGE_STATUS_UPDATED) + BGE_SETBIT(sc, BGE_MISC_LOCAL_CTL, BGE_MLC_INTR_SET); + else + CSR_WRITE_4(sc, BGE_HCC_MODE, BGE_HCCMODE_ENABLE | + BGE_HCCMODE_COAL_NOW); + } + callout_reset(&sc->bge_stat_ch, hz, bge_tick, sc); } Index: if_bgereg.h =================================================================== RCS file: /home/ncvs/src/sys/dev/bge/if_bgereg.h,v retrieving revision 1.52 diff -u -p -r1.52 if_bgereg.h --- if_bgereg.h 23 Aug 2006 11:32:54 -0000 1.52 +++ if_bgereg.h 24 Aug 2006 13:06:05 -0000 @@ -205,6 +205,7 @@ #define BGE_PCIMISCCTL_CLOCKCTL_RW 0x00000020 #define BGE_PCIMISCCTL_REG_WORDSWAP 0x00000040 #define BGE_PCIMISCCTL_INDIRECT_ACCESS 0x00000080 +#define BGE_PCIMISCCTL_TAGGED_STATUS 0x00000200 #define BGE_PCIMISCCTL_ASICREV 0xFFFF0000 #define BGE_HIF_SWAP_OPTIONS (BGE_PCIMISCCTL_ENDIAN_WORDSWAP) @@ -218,10 +219,6 @@ BGE_MODECTL_BYTESWAP_DATA|BGE_MODECTL_WORDSWAP_DATA #endif -#define BGE_INIT \ - (BGE_HIF_SWAP_OPTIONS|BGE_PCIMISCCTL_CLEAR_INTA| \ - BGE_PCIMISCCTL_MASK_PCI_INTR|BGE_PCIMISCCTL_INDIRECT_ACCESS) - #define BGE_CHIPID_TIGON_I 0x40000000 #define BGE_CHIPID_TIGON_II 0x60000000 #define BGE_CHIPID_BCM5700_A0 0x70000000 @@ -1190,6 +1187,8 @@ #define BGE_STATBLKSZ_FULL 0x00000000 #define BGE_STATBLKSZ_64BYTE 0x00000080 #define BGE_STATBLKSZ_32BYTE 0x00000100 +#define BGE_HCCMODE_CLRTICK_RXBD 0x00000200 +#define BGE_HCCMODE_CLRTICK_TXBD 0x00000400 /* Host coalescing status register */ #define BGE_HCCSTAT_ERROR 0x00000004 @@ -1684,6 +1683,9 @@ /* Misc. config register */ #define BGE_MISCCFG_RESET_CORE_CLOCKS 0x00000001 #define BGE_MISCCFG_TIMER_PRESCALER 0x000000FE +#define BGE_MISCCFG_BOARD_ID_MASK 0x0001e000 +#define BGE_MISCCFG_BOARD_ID_5788 0x00010000 +#define BGE_MISCCFG_BOARD_ID_5788M 0x00018000 #define BGE_32BITTIME_66MHZ (0x41 << 1) @@ -1932,7 +1934,10 @@ struct bge_sts_idx { struct bge_status_block { uint32_t bge_status; - uint32_t bge_rsvd0; +#define BGE_STATUS_UPDATED 0x00000001 +#define BGE_STATUS_LINKEV 0x00000002 +#define BGE_STATUS_ERROR 0x00000004 + uint32_t bge_tag; #if BYTE_ORDER == LITTLE_ENDIAN uint16_t bge_rx_jumbo_cons_idx; uint16_t bge_rx_std_cons_idx; @@ -2451,11 +2456,14 @@ struct bge_softc { #define BGE_FLAG_NO3LED 0x00000008 #define BGE_FLAG_PCIX 0x00000010 #define BGE_FLAG_PCIE 0x00000020 +#define BGE_FLAG_5788 0x00000040 +#define BGE_FLAG_STATUSTAG 0x00000080 uint32_t bge_chipid; uint8_t bge_asicrev; uint8_t bge_chiprev; struct bge_ring_data bge_ldata; /* rings */ struct bge_chain_data bge_cdata; /* mbufs */ + uint32_t bge_last_tag; uint16_t bge_tx_saved_considx; uint16_t bge_rx_saved_considx; uint16_t bge_ev_saved_considx; @@ -2474,6 +2482,9 @@ struct bge_softc { int bge_link; /* link state */ int bge_link_evt; /* pending link event */ struct callout bge_stat_ch; + /* Masks/values for some registers. */ + uint32_t bge_hcc_mode; /* BGE_HCC_MODE */ + uint32_t bge_misc_ctl; /* BGE_PCI_MISC_CTL */ char *bge_vpd_prodname; char *bge_vpd_readonly; u_long bge_rx_discards; --Fig2xvG2VGoz8o/s-- From owner-freebsd-net@FreeBSD.ORG Thu Aug 24 13:29:19 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EC0C616A4E2; Thu, 24 Aug 2006 13:29:19 +0000 (UTC) (envelope-from fli+freebsd-net@shapeshifter.se) Received: from mx1.h3q.net (manticore.shapeshifter.se [212.37.5.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id B66BD43D5D; Thu, 24 Aug 2006 13:29:14 +0000 (GMT) (envelope-from fli+freebsd-net@shapeshifter.se) Received: from localhost (localhost [127.0.0.1]) by mx1.h3q.net (Postfix) with ESMTP id 611B51A78D; Thu, 24 Aug 2006 15:29:12 +0200 (CEST) Received: from mx1.h3q.net ([127.0.0.1]) by localhost (mx1.h3q.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28835-06; Thu, 24 Aug 2006 15:29:11 +0200 (CEST) Received: from [192.168.1.100] (217-208-33-252-o926.tbon.telia.com [217.208.33.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.h3q.net (Postfix) with ESMTP id 4C6841A72A; Thu, 24 Aug 2006 15:29:11 +0200 (CEST) Message-ID: <44EDA9A5.2050108@shapeshifter.se> Date: Thu, 24 Aug 2006 15:29:09 +0200 From: Fredrik Lindberg User-Agent: Thunderbird 1.5.0.4 (X11/20060727) MIME-Version: 1.0 To: Pat Lashley References: <44EA1926.2000501@shapeshifter.se> <9C04919EE684029A410DE208@garrett.local> <44EAC40E.9000904@shapeshifter.se> <3E654CC0217F90E20FCD806E@garrett.local> <44EC90B7.6090908@shapeshifter.se> <44ECB0F2.9040300@FreeBSD.org> <20060823212110.GD27961@lor.one-eyed-alien.net> <20060823221835.GA28978@lor.one-eyed-alien.net> <23D2619F6BACE4E728178EE5@garrett.local> <44ED3BD1.3030206@shapeshifter.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at h3q.net Cc: freebsd-net@freebsd.org, Doug Barton Subject: Re: Zeroconfig and Multicast DNS 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, 24 Aug 2006 13:29:20 -0000 Pat Lashley wrote: >> Um..wouldn't the routing code handle this? >> If you set a lla address and some other address on a interface like > 192.168.0.2 >> or something and then a default route of 192.168.0.1, I >> would assume that an application without specific knowledge that tries >> to contact an external address would get 192.168.0.2 as the source >> address and that the packet is sent to 192.168.0.1. > > It should handle it; but I'd still want someone to check out various > edge conditions and pathological cases. > >> If you're in the situation that you need lla (no dhcp server available), > > The presence or absence of a DHCP server is not a good indicator of the > need or desire for LLA and/or mDNS. It is quite possible that the system > is in a mixed environment where there are some systems which are > LLA/mDNS only, others which are DHCP/static/unicast DNS only, and others > which handle both. > > I treat LLA and mDNS as separate things. They can be used individually or together. I see LLA as a way of configuring an IP-address while mDNS is a way of resolving DNS-like hostnames. Howevery, your statement above brings up a question, do you assume that a system configured with lla should be able to communicate with a system configured via dhcp? I would assume no, per standard IP/routing rules as they would be in different subnets and would require a router to tell them about each other which somehow violates the link local scope of the 169.254/16 address space. >> you wouldn't know the default route right? > > I believe that there is a way to announce routing service via mDNS-SD; > but I don't know the details. (I would be astonished to discover that > the people who developed the zeroconfig design left that bit out...) > Yes, discovering a NAT-router via SD is certainly possible, but I'm not sure if this should be in the lla-daemon or in a separate program. Fredrik Lindberg From owner-freebsd-net@FreeBSD.ORG Thu Aug 24 14:00:20 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C9B3616A4DE; Thu, 24 Aug 2006 14:00:19 +0000 (UTC) (envelope-from patl+freebsd@volant.org) Received: from smtp.volant.org (gate.volant.org [207.111.218.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 16DBB43D45; Thu, 24 Aug 2006 14:00:18 +0000 (GMT) (envelope-from patl+freebsd@volant.org) Received: from adsl-065-081-071-131.sip.gnv.bellsouth.net ([65.81.71.131] helo=[192.168.1.121]) by smtp.volant.org with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34 (FreeBSD)) id 1GGFno-000LPl-6h; Thu, 24 Aug 2006 07:03:37 -0700 Date: Thu, 24 Aug 2006 06:59:11 -0400 From: Pat Lashley To: Ian Smith Message-ID: <4361C9398E9A195D2FB0B011@garrett.local> In-Reply-To: References: X-Mailer: Mulberry/4.0.0 (Mac OS X) MIME-Version: 1.0 X-Scan-Signature: f3aa23ad20e1cc3932a917aa9dad209a1876c77b X-Spam-User: nobody X-Spam-Score: -4.1 (----) X-Spam-Score-Int: -40 X-Spam-Report: This mail has matched the spam-filter tests listed below. See http://spamassassin.org/tag/ for details about the specific tests reported. In general, the higher the number of total points, the more likely that it actually is spam. (The 'required' number of points listed below is the arbitrary number above which the message is normally considered spam.) Content analysis details: (-4.1 points total, 5.0 required) 0.1 HTML_MESSAGE BODY: HTML included in message 0.1 HTML_FONTCOLOR_RED BODY: HTML font color is red -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.4 DATE_IN_PAST_03_06 Date: is 3 to 6 hours before Received: date 0.2 AWL AWL: Auto-whitelist adjustment Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, Doug Barton , Fredrik Lindberg Subject: Re: Zeroconfig and Multicast DNS 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, 24 Aug 2006 14:00:20 -0000 > I've been watching this thread with great interest, having recently been > introduced to the possibilities of OLSR (net/olsrd) for local (and > beyond) P2P wi-mesh networks, and wondering if/how zeroconf fits in. > > Some refs: My discovery point, a great (online) book found from a review > by Geoff Huston in the Internet Protocol Journal Vol 9 No 2, p44: > > Wireless Networking in the Developing World: http://wndw.net/ > OLSR.ORG: http://www.olsr.org/ > RFC: http://ietf.org/rfc/rfc3626.txt (basis, though olsrd extends this) > > Host addresses in such a MANET appear to require manual allocation so > far, usually in RFC1918 ranges, but the notion of zeroconfig-joining > such a network seems perhaps worthy of exploration? > > Am I way off base here, thinking some matchmaking might be useful? This is all off the top of my head... For a small enough mesh, with low enough latencies, I believe that you could just define the entire mesh as one link, sharing a single instance if the Link Local IP range. Everything acting as a router/bridge would have to propagate the various LLA packets throughout the mesh but avoid sending them off-mesh. OLSP or other ad-hoc routing protocols should handle that setup as well as if every host had a static IP. (I don't remember the details of LLA, but I know that mDNS needs multicast support. So you would need an ad-hoc routing mechanism that supports multicast to get a full zeroconf mesh with DNS and service discovery.) But the design would start to break down as the mesh grows large enough to either use a significant percentage of the LL address range or to make end-to-end latency significant. I can think of a couple of potential approaches to designing a federation of smaller meshes; but they all have some pretty tricky issues to resolve. I strongly suspect that it would be simpler to just build your mesh using IPv6 only; and to provide 6-to-4 (NAT?) conversion at the interfaces between the mesh and the WAN. (The IPv6 address range is large enough that every interface already has a globally unique link-local address; so no need to negotiate, defend, or change the IP addresses as things move around.) Also, I'm not familiar with OLSP; but I note that it apparently actively discovers nodes one and two hops away. It isn't clear to me how it handles routing to anything further than two hops. I also note that there are a mind-boggling number of ad-hoc routing protocols to choose from... -Pat From owner-freebsd-net@FreeBSD.ORG Thu Aug 24 14:30:25 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AF10316A4DF; Thu, 24 Aug 2006 14:30:25 +0000 (UTC) (envelope-from patl+freebsd@volant.org) Received: from smtp.volant.org (gate.volant.org [207.111.218.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4CB4143D8C; Thu, 24 Aug 2006 14:30:16 +0000 (GMT) (envelope-from patl+freebsd@volant.org) Received: from adsl-065-081-071-131.sip.gnv.bellsouth.net ([65.81.71.131] helo=[192.168.1.121]) by smtp.volant.org with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34 (FreeBSD)) id 1GGGH0-000Lj0-9A; Thu, 24 Aug 2006 07:33:40 -0700 Date: Thu, 24 Aug 2006 07:29:23 -0400 From: Pat Lashley To: Fredrik Lindberg Message-ID: In-Reply-To: <44EDA9A5.2050108@shapeshifter.se> References: <44EA1926.2000501@shapeshifter.se> <9C04919EE684029A410DE208@garrett.local> <44EAC40E.9000904@shapeshifter.se> <3E654CC0217F90E20FCD806E@garrett.local> <44EC90B7.6090908@shapeshifter.se> <44ECB0F2.9040300@FreeBSD.org> <20060823212110.GD27961@lor.one-eyed-alien.net> <20060823221835.GA28978@lor.one-eyed-alien.net> <23D2619F6BACE4E728178EE5@garrett.local> <44ED3BD1.3030206@shapeshifter.se> <44EDA9A5.2050108@shapeshifter.se> X-Mailer: Mulberry/4.0.0 (Mac OS X) MIME-Version: 1.0 X-Scan-Signature: 9dd6e96fed736b9892f077ba19b25bfcfe41deb2 X-Spam-User: nobody X-Spam-Score: -4.1 (----) X-Spam-Score-Int: -40 X-Spam-Report: This mail has matched the spam-filter tests listed below. See http://spamassassin.org/tag/ for details about the specific tests reported. In general, the higher the number of total points, the more likely that it actually is spam. (The 'required' number of points listed below is the arbitrary number above which the message is normally considered spam.) Content analysis details: (-4.1 points total, 5.0 required) 0.1 HTML_MESSAGE BODY: HTML included in message 0.1 HTML_FONTCOLOR_RED BODY: HTML font color is red -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.4 DATE_IN_PAST_03_06 Date: is 3 to 6 hours before Received: date 0.2 AWL AWL: Auto-whitelist adjustment Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, Doug Barton Subject: Re: Zeroconfig and Multicast DNS 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, 24 Aug 2006 14:30:25 -0000 > I treat LLA and mDNS as separate things. They can be used individually > or together. I see LLA as a way of configuring an IP-address while > mDNS is a way of resolving DNS-like hostnames. Don't forget service discovery. That's an important part of zeroconf, implemented via mDNS. > Howevery, your statement above brings up a question, do you assume > that a system configured with lla should be able to communicate > with a system configured via dhcp? Yes, of course. The question is basically the same as whether hosts on the same link but different IP (sub)net ranges should be able to communicate with each other. The answer is that either both hosts must implement ARP/RARP functionality, or that there be at least one additional host with addresses in both ranges that is willing to act as a router. > I would assume no, per standard IP/routing rules as they would be > in different subnets and would require a router to tell them > about each other which somehow violates the link local scope of > the 169.254/16 address space. No, it does not violate the link local scope as long as the router performs NAT to translate the 169.254/16 address into something else. And I don't think that the RFC forbids non-LLA hosts on the same link from knowing about link local addresses or communicating directly with hosts that only have LLAs. The important thing is that the link local addresses not be visible outside the link. (Which means that we may need some special purpose code in routed to prevent it from advertising 169.254/16 routes.) > Yes, discovering a NAT-router via SD is certainly possible, but I'm not > sure if this should be in the lla-daemon or in a separate program. I would expect it to be handled like any other service - it is a function of mDNS-SD, not LLA; and it is up to the service consumer to do the discovery. In this case, the consumer would be some script/utility/daemon to update the system's routing table. -Pat From owner-freebsd-net@FreeBSD.ORG Thu Aug 24 14:55:27 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D9E3216A4DF; Thu, 24 Aug 2006 14:55:27 +0000 (UTC) (envelope-from fli+freebsd-net@shapeshifter.se) Received: from mx1.h3q.net (manticore.shapeshifter.se [212.37.5.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2E8E943D76; Thu, 24 Aug 2006 14:55:22 +0000 (GMT) (envelope-from fli+freebsd-net@shapeshifter.se) Received: from localhost (localhost [127.0.0.1]) by mx1.h3q.net (Postfix) with ESMTP id 774CA1A78D; Thu, 24 Aug 2006 16:55:19 +0200 (CEST) Received: from mx1.h3q.net ([127.0.0.1]) by localhost (mx1.h3q.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29792-08; Thu, 24 Aug 2006 16:55:16 +0200 (CEST) Received: from [192.168.1.100] (217-208-33-252-o926.tbon.telia.com [217.208.33.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.h3q.net (Postfix) with ESMTP id 65C761A78E; Thu, 24 Aug 2006 16:55:16 +0200 (CEST) Message-ID: <44EDBDD0.4050000@shapeshifter.se> Date: Thu, 24 Aug 2006 16:55:12 +0200 From: Fredrik Lindberg User-Agent: Thunderbird 1.5.0.4 (X11/20060727) MIME-Version: 1.0 To: Pat Lashley References: <44EA1926.2000501@shapeshifter.se> <9C04919EE684029A410DE208@garrett.local> <44EAC40E.9000904@shapeshifter.se> <3E654CC0217F90E20FCD806E@garrett.local> <44EC90B7.6090908@shapeshifter.se> <44ECB0F2.9040300@FreeBSD.org> <20060823212110.GD27961@lor.one-eyed-alien.net> <20060823221835.GA28978@lor.one-eyed-alien.net> <23D2619F6BACE4E728178EE5@garrett.local> <44ED3BD1.3030206@shapeshifter.se> <44EDA9A5.2050108@shapeshifter.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at h3q.net Cc: freebsd-net@freebsd.org, Doug Barton Subject: Re: Zeroconfig and Multicast DNS 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, 24 Aug 2006 14:55:27 -0000 Pat Lashley wrote: >> I treat LLA and mDNS as separate things. They can be used individually >> or together. I see LLA as a way of configuring an IP-address while >> mDNS is a way of resolving DNS-like hostnames. > > Don't forget service discovery. That's an important part of zeroconf, > implemented via mDNS. I'm not. But LLA can run without mDNS and mDNS can run without LLA, but SD requires mDNS. > >> Howevery, your statement above brings up a question, do you assume >> that a system configured with lla should be able to communicate >> with a system configured via dhcp? > > Yes, of course. The question is basically the same as whether hosts on > the same link but different IP (sub)net ranges should be able to > communicate with each other. The answer is that either both hosts must > implement ARP/RARP functionality, or that there be at least one > additional host with addresses in both ranges that is willing to act as > a router. Of course it's possible with a router, but what I was after, was the situation when a host is configured with LLA but without a default route , should such host be able to communicate with other hosts on the same link that has addresses configured in other ranges (obtained by other utilities, dhcp, static etc). If the answer to that is yes, how is it supposed to work? Should the routing code be change to always issue a ARP request when the source is from 169.254/16 ? The responding host will have to implement the same algorithm or it will just send the packet to its default router which probably wouldn't know what to do with the packet and throw it away. Could be pretty ugly. I also don't see how RARP would help because that would require the host to have knowledge of the other hosts MAC-address. Fredrik Lindberg From owner-freebsd-net@FreeBSD.ORG Thu Aug 24 15:12:35 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2ABFB16A4DA; Thu, 24 Aug 2006 15:12:35 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from sccmmhc92.asp.att.net (sccmmhc92.asp.att.net [204.127.203.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D3C243D49; Thu, 24 Aug 2006 15:12:33 +0000 (GMT) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net ([12.207.12.9]) by sccmmhc92.asp.att.net (sccmmhc92) with ESMTP id <20060824151232m92002taode>; Thu, 24 Aug 2006 15:12:32 +0000 Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.13.6/8.13.6) with ESMTP id k7OFCT1I036715; Thu, 24 Aug 2006 10:12:29 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.13.6/8.13.6/Submit) id k7OFCRbp036714; Thu, 24 Aug 2006 10:12:27 -0500 (CDT) (envelope-from brooks) Date: Thu, 24 Aug 2006 10:12:27 -0500 From: Brooks Davis To: Fredrik Lindberg Message-ID: <20060824151227.GC35200@lor.one-eyed-alien.net> References: <20060823212110.GD27961@lor.one-eyed-alien.net> <20060823221835.GA28978@lor.one-eyed-alien.net> <23D2619F6BACE4E728178EE5@garrett.local> <44ED3BD1.3030206@shapeshifter.se> <44EDA9A5.2050108@shapeshifter.se> <44EDBDD0.4050000@shapeshifter.se> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Sr1nOIr3CvdE5hEN" Content-Disposition: inline In-Reply-To: <44EDBDD0.4050000@shapeshifter.se> User-Agent: Mutt/1.5.11 Cc: freebsd-net@freebsd.org, Pat Lashley , Doug Barton Subject: Re: Zeroconfig and Multicast DNS 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, 24 Aug 2006 15:12:35 -0000 --Sr1nOIr3CvdE5hEN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 24, 2006 at 04:55:12PM +0200, Fredrik Lindberg wrote: > Pat Lashley wrote: > >>I treat LLA and mDNS as separate things. They can be used individually > >>or together. I see LLA as a way of configuring an IP-address while > >>mDNS is a way of resolving DNS-like hostnames. > > > >Don't forget service discovery. That's an important part of zeroconf,=20 > >implemented via mDNS. >=20 > I'm not. But LLA can run without mDNS and mDNS can run without LLA, but > SD requires mDNS. >=20 > > > >>Howevery, your statement above brings up a question, do you assume > >>that a system configured with lla should be able to communicate > >>with a system configured via dhcp? > > > >Yes, of course. The question is basically the same as whether hosts on= =20 > >the same link but different IP (sub)net ranges should be able to=20 > >communicate with each other. The answer is that either both hosts must= =20 > >implement ARP/RARP functionality, or that there be at least one=20 > >additional host with addresses in both ranges that is willing to act as= =20 > >a router. >=20 > Of course it's possible with a router, but what I was after, was the > situation when a host is configured with LLA but without a default route > , should such host be able to communicate with other hosts on the > same link that has addresses configured in other ranges (obtained by > other utilities, dhcp, static etc). Yes, but in general if and only if it has an address in those ranges. While it tends to be confusing and can lead to brokenness, there's nothing wrong with configuring addresses for multiple subnets on the same interface. The one exception is a configuration where you have an interface route and make ARP requests for all addresses rather than explicitly specifing a specific default router, but that's probably not the right default configuration (useful though it could be). To really make that work well I thing we need the ability to handle multiple default routes and assign them priorities. -- Brooks --Sr1nOIr3CvdE5hEN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFE7cHaXY6L6fI4GtQRAsfQAJ9fgJn0PAP1969hGhjp0rlBphF3LgCgzvjL YsGFTxllkoG4PqSzVXaUe70= =TW9C -----END PGP SIGNATURE----- --Sr1nOIr3CvdE5hEN-- From owner-freebsd-net@FreeBSD.ORG Thu Aug 24 15:29:30 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0A7E016A4DE; Thu, 24 Aug 2006 15:29:30 +0000 (UTC) (envelope-from patl@volant.org) Received: from smtp.volant.org (gate.volant.org [207.111.218.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C12543D45; Thu, 24 Aug 2006 15:29:29 +0000 (GMT) (envelope-from patl@volant.org) Received: from adsl-065-081-071-131.sip.gnv.bellsouth.net ([65.81.71.131] helo=[192.168.1.121]) by smtp.volant.org with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34 (FreeBSD)) id 1GGHBx-000MLJ-8M; Thu, 24 Aug 2006 08:32:51 -0700 Date: Thu, 24 Aug 2006 08:28:10 -0400 From: Pat Lashley To: Fredrik Lindberg Message-ID: <7C6CDF1CB0BC58A6ADE1FCA8@garrett.local> In-Reply-To: <44ED8266.1060303@shapeshifter.se> References: <44E9F991.7020309@shapeshifter.se> <44EA1926.2000501@shapeshifter.se> <9C04919EE684029A410DE208@garrett.local> <44EAC40E.9000904@shapeshifter.se> <3E654CC0217F90E20FCD806E@garrett.local> <44EC90B7.6090908@shapeshifter.se> <44ECB0F2.9040300@FreeBSD.org> <44ECBB61.9020808@shapeshifter.se> <5D7785ADC030FEBFB9A5E69D@garrett.local> <44ED8266.1060303@shapeshifter.se> X-Mailer: Mulberry/4.0.0 (Mac OS X) MIME-Version: 1.0 X-Scan-Signature: aa7821ecc2a1e5da07325fd6162a7699999fbd44 X-Spam-User: nobody X-Spam-Score: -1.4 (-) X-Spam-Score-Int: -13 X-Spam-Report: This mail has matched the spam-filter tests listed below. See http://spamassassin.org/tag/ for details about the specific tests reported. In general, the higher the number of total points, the more likely that it actually is spam. (The 'required' number of points listed below is the arbitrary number above which the message is normally considered spam.) Content analysis details: (-1.4 points total, 5.0 required) 2.2 DOMAIN_BODY BODY: Domain registration spam body 0.1 HTML_MESSAGE BODY: HTML included in message 0.1 HTML_FONTCOLOR_RED BODY: HTML font color is red -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.4 DATE_IN_PAST_03_06 Date: is 3 to 6 hours before Received: date 0.7 AWL AWL: Auto-whitelist adjustment Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, Doug Barton Subject: Re: Zeroconfig and Multicast DNS 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, 24 Aug 2006 15:29:30 -0000 > I should probably explain better what I mean with this mdns.conf file, > as I think there might be a misunderstanding about it. > > Let us for a second pretend that SD doesn't exist but mDNS does, mDNS > without SD is still a very valuable protocol. No argument there. > The specs. says that each host should claim a unique host and also > advertise a HINFO record, but this in my opinion a policy decision > and should be left to the end user. The HINFO record should be a policy decision; but I'm much less certain about the utility of not advertising a hostname. > A user might want to advertise 0, 1, 2 or many different unique records, > and the main purpose of the mdns.conf file would be to provide a easy > way to do so (without writing scripts that calls a cmd line utility). > For example, a line in the mdns.conf might look like this > > $(hostname).local. A $(ifaddr) > > Might look cryptic but it just means announce a A record using my > current hostname, append .local. and point it to whatever ip number > that happens to be configured on my interface. Things get a bit more complex for multi-homed hosts; especially if they are connected to more than one local link using IPv4 Link Local Addressing... > These variables would > be updated when things happen in the system (new ip address etc) > Also, there is no technical limitation in the mDNS protocol that > prevents it from working with other TLDs, so which TLD to use should > also be up to the user (again a policy decision). As I mentioned in an earlier posting, I would really like to see it support multiple TLDs for a single host. In particular, if I'm using example.com, then mumble.local and mumble.example.com should both resolve via mDNS to the IP address of host mumble. Similarly, services advertised by host mumble should automatically be listed in both domains. If we're going to require an entry in a config file to get address advertisement; then we need to ensure that the default config file Does The Right Thing for the 99.99% case. (Otherwise, it isn't really zeroconf, is it?) I think that it would be best if the most common cases worked correctly without a config file at all. Command-line flags set via /etc/rc.conf can indicate interfaces that are (not) to be used, whether or not to automatically produce an HINFO record, and whether to advertise all (except 127/8) or none of the /etc/hosts records. Doing this via rc.conf makes it much easier to set up common options at install time via sysinstall. The config file, if provided would specify additional hosts that don't advertise themselves; and additional services provided by hosts that don't advertise. It would also be used to specify a non-default HINFO record format. (I'm thinking a string with various % substitutions available.) Note that whether or not to produce an HINFO record at all would still be handled by the command line. > Now we can get back to the reality where SD does exists. > In addition to this mdns.conf we have the client API, using this > client API a command line tool should be built that can insert > and remove records (even those records configured using mdns.conf). > Lets call this tool mdns for now (the name it doesn't matter, and > isn't really the point). > > Programs announcing a service using SD would preferably call the > mdns tool in their rc.d scripts to add/remove SD records. No, programs announcing a service using SD would preferably make a call to the mdns-sd library. The use of the mdnstool in the rc.d script should probably be viewed as the preferred method during the transition period between bundling the basic mDNS support and converting the service providers to being directly mDNS-aware. > > Right. Except for the additional bit of knowledge about the .local domain. > > > > I've been thinking about this too. The NSS module would require a file > similar to resolv.conf. It would contain a "white list" of allowed > domains to resolv (local., 168.192.in-addr.arpa., 10.in-addr.arpa etc). > But it could also contain a "search" directive so that if it receives > a query for a name without a white listed TLD it appends for > example ".local." to the name. > > It might be dangerous though as it could try to query for > www.google.com.local., a solution to this would be do "blacklist" > existing TLDs when a search is done or only to do a search if there are > no dots in the name, I think the latter solution is the best > Anyway, it would allow users to leave out the .local part when communicating > which I think would be a nice feature. Is that really necessary? I haven't looked at how the resolver handles the domain search list and how that relates to NSS calls; but couldn't it be handled by implicitly adding 'local' to the list? -Pat From owner-freebsd-net@FreeBSD.ORG Thu Aug 24 16:07:36 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 14FBA16A4DA; Thu, 24 Aug 2006 16:07:36 +0000 (UTC) (envelope-from fli+freebsd-net@shapeshifter.se) Received: from mx1.h3q.net (manticore.shapeshifter.se [212.37.5.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6D8DD43D45; Thu, 24 Aug 2006 16:07:35 +0000 (GMT) (envelope-from fli+freebsd-net@shapeshifter.se) Received: from localhost (localhost [127.0.0.1]) by mx1.h3q.net (Postfix) with ESMTP id 24E5C1A78D; Thu, 24 Aug 2006 18:07:33 +0200 (CEST) Received: from mx1.h3q.net ([127.0.0.1]) by localhost (mx1.h3q.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30634-09; Thu, 24 Aug 2006 18:07:31 +0200 (CEST) Received: from [192.168.1.100] (217-208-33-252-o926.tbon.telia.com [217.208.33.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.h3q.net (Postfix) with ESMTP id 544361A72A; Thu, 24 Aug 2006 18:07:31 +0200 (CEST) Message-ID: <44EDCEC2.7060109@shapeshifter.se> Date: Thu, 24 Aug 2006 18:07:30 +0200 From: Fredrik Lindberg User-Agent: Thunderbird 1.5.0.4 (X11/20060727) MIME-Version: 1.0 To: Pat Lashley References: <44E9F991.7020309@shapeshifter.se> <44EA1926.2000501@shapeshifter.se> <9C04919EE684029A410DE208@garrett.local> <44EAC40E.9000904@shapeshifter.se> <3E654CC0217F90E20FCD806E@garrett.local> <44EC90B7.6090908@shapeshifter.se> <44ECB0F2.9040300@FreeBSD.org> <44ECBB61.9020808@shapeshifter.se> <5D7785ADC030FEBFB9A5E69D@garrett.local> <44ED8266.1060303@shapeshifter.se> <7C6CDF1CB0BC58A6ADE1FCA8@garrett.local> In-Reply-To: <7C6CDF1CB0BC58A6ADE1FCA8@garrett.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at h3q.net Cc: freebsd-net@freebsd.org, Doug Barton Subject: Re: Zeroconfig and Multicast DNS 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, 24 Aug 2006 16:07:36 -0000 Pat Lashley wrote: >> >> Let us for a second pretend that SD doesn't exist but mDNS does, mDNS >> without SD is still a very valuable protocol. > > No argument there. > >> The specs. says that each host should claim a unique host and also >> advertise a HINFO record, but this in my opinion a policy decision >> and should be left to the end user. > > The HINFO record should be a policy decision; but I'm much less certain > about the utility of not advertising a hostname. Well, then we can agree upon disagreeing :) I guess it's just my nature, I really don't want to restrict end users ability to do stuff when there is no TECHNICAL limitation of doing so. It's the classical policy versus mechanism scenario, imho policy should be left to the user, of course provided with sane default values that can be used out of the box. > >> A user might want to advertise 0, 1, 2 or many different unique records, >> and the main purpose of the mdns.conf file would be to provide a easy >> way to do so (without writing scripts that calls a cmd line utility). >> For example, a line in the mdns.conf might look like this >> >> $(hostname).local. A $(ifaddr) >> >> Might look cryptic but it just means announce a A record using my >> current hostname, append .local. and point it to whatever ip number >> that happens to be configured on my interface. > > Things get a bit more complex for multi-homed hosts; especially if they > are connected to more than one local link using IPv4 Link Local > Addressing... Well, I already have a proof-of-concept of this running a multi-homed responder and hosts on both ends resolve the addresses correct. A multi-homed host with two interfaces configured in 169.254/16 will have other major problems beyond mDNS as the host would threat both interfaces as being on the same net even if they are physically separated. > > As I mentioned in an earlier posting, I would really like to see it > support multiple TLDs for a single host. In particular, if I'm using > example.com, then mumble.local and mumble.example.com should both > resolve via mDNS to the IP address of host mumble. Similarly, services > advertised by host mumble should automatically be listed in both domains. Well, $(hostname).example.com. A $(ifaddr) :) You would have to configure the NSS module to allow .com queries too. > > If we're going to require an entry in a config file to get address > advertisement; then we need to ensure that the default config file Does > The Right Thing for the 99.99% case. (Otherwise, it isn't really > zeroconf, is it?) Of course, default configuration should always be such that it requires none or minimal work by the end user to get it running with values that suite most people. However I feel power-users shouldn't be restricted to do what ever they want, even how crazy other people might think it is. The default of my proof-of-concept stuff had this as default, which means advertise a A and a PTR record for my hostname on all interfaces using the address of the interface. (should be expanded with AAAA and $(ifaddr6) in a real application). interface * { $(hostname).local. A $(ifaddr) $(ifaddr) PTR $(hostname).local. } > > > I think that it would be best if the most common cases worked correctly > without a config file at all. Command-line flags set via /etc/rc.conf > can indicate interfaces that are (not) to be used, whether or not to > automatically produce an HINFO record, and whether to advertise all > (except 127/8) or none of the /etc/hosts records. Doing this via rc.conf > makes it much easier to set up common options at install time via > sysinstall. I really don't understand how it should read /etc/hosts, users might have aliases in there that doesn't belong to them which would make the responder announce records that doesn't belong to them. > > The config file, if provided would specify additional hosts that don't > advertise themselves; and additional services provided by hosts that > don't advertise. It would also be used to specify a non-default HINFO > record format. (I'm thinking a string with various % substitutions > available.) Note that whether or not to produce an HINFO record at all > would still be handled by the command line. > >> Now we can get back to the reality where SD does exists. >> In addition to this mdns.conf we have the client API, using this >> client API a command line tool should be built that can insert >> and remove records (even those records configured using mdns.conf). >> Lets call this tool mdns for now (the name it doesn't matter, and >> isn't really the point). >> >> Programs announcing a service using SD would preferably call the >> mdns tool in their rc.d scripts to add/remove SD records. > > No, programs announcing a service using SD would preferably make a call > to the mdns-sd library. The use of the mdnstool in the rc.d script > should probably be viewed as the preferred method during the transition > period between bundling the basic mDNS support and converting the > service providers to being directly mDNS-aware. Yeah, on a second though I agree with that. > >> > Right. Except for the additional bit of knowledge about the .local >> domain. >> > >> >> I've been thinking about this too. The NSS module would require a file >> similar to resolv.conf. It would contain a "white list" of allowed >> domains to resolv (local., 168.192.in-addr.arpa., 10.in-addr.arpa etc). >> But it could also contain a "search" directive so that if it receives >> a query for a name without a white listed TLD it appends for >> example ".local." to the name. >> >> It might be dangerous though as it could try to query for >> www.google.com.local., a solution to this would be do "blacklist" >> existing TLDs when a search is done or only to do a search if there are >> no dots in the name, I think the latter solution is the best >> Anyway, it would allow users to leave out the .local part when >> communicating >> which I think would be a nice feature. > > Is that really necessary? I haven't looked at how the resolver handles > the domain search list and how that relates to NSS calls; but couldn't > it be handled by implicitly adding 'local' to the list? > I was under the impression that resolv.conf was explicitly used by the dns nss module, but I could be wrong. The mDNS will requires its own nss module that should be independent from the other DNS. Fredrik Lindberg From owner-freebsd-net@FreeBSD.ORG Thu Aug 24 16:21:25 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D06FC16A4E2; Thu, 24 Aug 2006 16:21:25 +0000 (UTC) (envelope-from patl@volant.org) Received: from smtp.volant.org (gate.volant.org [207.111.218.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2FADD43D46; Thu, 24 Aug 2006 16:21:25 +0000 (GMT) (envelope-from patl@volant.org) Received: from adsl-065-081-071-131.sip.gnv.bellsouth.net ([65.81.71.131] helo=[192.168.1.121]) by smtp.volant.org with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34 (FreeBSD)) id 1GGI0X-000MpK-Dm; Thu, 24 Aug 2006 09:24:47 -0700 Date: Thu, 24 Aug 2006 09:20:29 -0400 From: Pat Lashley To: Fredrik Lindberg Message-ID: <7CC9AC69410B69EBD31122E4@garrett.local> In-Reply-To: <44EDBDD0.4050000@shapeshifter.se> References: <44EA1926.2000501@shapeshifter.se> <9C04919EE684029A410DE208@garrett.local> <44EAC40E.9000904@shapeshifter.se> <3E654CC0217F90E20FCD806E@garrett.local> <44EC90B7.6090908@shapeshifter.se> <44ECB0F2.9040300@FreeBSD.org> <20060823212110.GD27961@lor.one-eyed-alien.net> <20060823221835.GA28978@lor.one-eyed-alien.net> <23D2619F6BACE4E728178EE5@garrett.local> <44ED3BD1.3030206@shapeshifter.se> <44EDA9A5.2050108@shapeshifter.se> <44EDBDD0.4050000@shapeshifter.se> X-Mailer: Mulberry/4.0.0 (Mac OS X) MIME-Version: 1.0 X-Scan-Signature: 8a7379b8f090bcbc03cb3e1ca11299a5c9f3efe8 X-Spam-User: nobody X-Spam-Score: -2.5 (--) X-Spam-Score-Int: -24 X-Spam-Report: This mail has matched the spam-filter tests listed below. See http://spamassassin.org/tag/ for details about the specific tests reported. In general, the higher the number of total points, the more likely that it actually is spam. (The 'required' number of points listed below is the arbitrary number above which the message is normally considered spam.) Content analysis details: (-2.5 points total, 5.0 required) 0.1 HTML_MESSAGE BODY: HTML included in message 0.1 HTML_FONTCOLOR_RED BODY: HTML font color is red -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.4 DATE_IN_PAST_03_06 Date: is 3 to 6 hours before Received: date 1.8 AWL AWL: Auto-whitelist adjustment Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, Doug Barton Subject: Re: Zeroconfig and Multicast DNS 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, 24 Aug 2006 16:21:25 -0000 > >> Howevery, your statement above brings up a question, do you assume > >> that a system configured with lla should be able to communicate > >> with a system configured via dhcp? > > > > Yes, of course. The question is basically the same as whether hosts on > > the same link but different IP (sub)net ranges should be able to > > communicate with each other. The answer is that either both hosts must > > implement ARP/RARP functionality, or that there be at least one > > additional host with addresses in both ranges that is willing to act as > > a router. > > Of course it's possible with a router, but what I was after, was the > situation when a host is configured with LLA but without a default route > , should such host be able to communicate with other hosts on the > same link that has addresses configured in other ranges (obtained by > other utilities, dhcp, static etc). That's one of those policy decisions for which there is no clear correct answer. > If the answer to that is yes, how is it supposed to work? > Should the routing code be change to always issue a ARP request when > the source is from 169.254/16 ? If the source is from an LLA, then the destination machine should already have the ARP info, extracted from the packet itself. The problem crops up when a non-LLA host wants to initiate a connection to an LLA host. > The responding host will have to > implement the same algorithm or it will just send the packet to its > default router which probably wouldn't know what to do with the packet > and throw it away. Could be pretty ugly. The default router is probably also the default router for LLA hosts; so it would send it to the right machine. (Unless local administrative policy prevents LLA hosts from having a default router...) But that extra hop is a bit ugly. But the whole 'direct communication between LLA and non-LLA on the same link' discussion is really a side issue. It should only come up for us in a scenario where we want to have a completely zeroconf FreeBSD machine (using LLA) in an environment with non-LLA machines. If the FreeBSD machine is getting a static or DHCP address and wants to talk to LLA machines; then it should also also obtain an LLA address as an alias so that it can readily talk to both subnets. (This is one of the reasons that I'm campaigning so strongly for doing the LLA addresses as an alias even if there is some other address available.) The difficulty, even for a pure LLA-scenario, is the case of a multi-homed host where more than one interface is using LLA, and the interfaces are on separate links. The problem is that you may have different hosts with the same link local IP address on each link. That raises some really ugly issues. One of the simplest is that for a multi-homed host, we can't just add '169/254/16 LINK#x' for each interface to the routing table and expect the right thing to happen. > I also don't see how RARP would help because that would require the > host to have knowledge of the other hosts MAC-address. Yep, definitely less helpful than ARP. But setups that use ARP often also enable RARP; so I tend to mention them together. -Pat From owner-freebsd-net@FreeBSD.ORG Thu Aug 24 17:02:09 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 21CF216A4E1; Thu, 24 Aug 2006 17:02:09 +0000 (UTC) (envelope-from fli+freebsd-net@shapeshifter.se) Received: from mx1.h3q.net (manticore.shapeshifter.se [212.37.5.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F7E543D45; Thu, 24 Aug 2006 17:02:08 +0000 (GMT) (envelope-from fli+freebsd-net@shapeshifter.se) Received: from localhost (localhost [127.0.0.1]) by mx1.h3q.net (Postfix) with ESMTP id 0264B1A78D; Thu, 24 Aug 2006 19:02:07 +0200 (CEST) Received: from mx1.h3q.net ([127.0.0.1]) by localhost (mx1.h3q.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31517-04; Thu, 24 Aug 2006 19:02:06 +0200 (CEST) Received: from [192.168.1.100] (217-208-33-252-o926.tbon.telia.com [217.208.33.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.h3q.net (Postfix) with ESMTP id 09A191A751; Thu, 24 Aug 2006 19:02:05 +0200 (CEST) Message-ID: <44EDDB8C.9090504@shapeshifter.se> Date: Thu, 24 Aug 2006 19:02:04 +0200 From: Fredrik Lindberg User-Agent: Thunderbird 1.5.0.4 (X11/20060727) MIME-Version: 1.0 To: Pat Lashley References: <44EA1926.2000501@shapeshifter.se> <9C04919EE684029A410DE208@garrett.local> <44EAC40E.9000904@shapeshifter.se> <3E654CC0217F90E20FCD806E@garrett.local> <44EC90B7.6090908@shapeshifter.se> <44ECB0F2.9040300@FreeBSD.org> <20060823212110.GD27961@lor.one-eyed-alien.net> <20060823221835.GA28978@lor.one-eyed-alien.net> <23D2619F6BACE4E728178EE5@garrett.local> <44ED3BD1.3030206@shapeshifter.se> <44EDA9A5.2050108@shapeshifter.se> <44EDBDD0.4050000@shapeshifter.se> <7CC9AC69410B69EBD31122E4@garrett.local> In-Reply-To: <7CC9AC69410B69EBD31122E4@garrett.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at h3q.net Cc: freebsd-net@freebsd.org, Doug Barton Subject: Re: Zeroconfig and Multicast DNS 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, 24 Aug 2006 17:02:09 -0000 Pat Lashley wrote: > > But the whole 'direct communication between LLA and non-LLA on the same > link' discussion is really a side issue. It should only come up for us > in a scenario where we want to have a completely zeroconf FreeBSD > machine (using LLA) in an environment with non-LLA machines. If the > FreeBSD machine is getting a static or DHCP address and wants to talk to > LLA machines; then it should also also obtain an LLA address as an alias > so that it can readily talk to both subnets. (This is one of the reasons > that I'm campaigning so strongly for doing the LLA addresses as an alias > even if there is some other address available.) > Ok, that was just what I wanted to hear. Seems like we have talked around each other. If you want to communicate with an LLA host, fine, obtain an LLA address otherwise take a hike. My LLA implementation already does this..it never removes an address from a interface it didn't set itself, and it always sets address as aliases. There is also an option to force it to assign (as an alias) a LLA address even if the interface is already is configured with another address. Fredrik Lindberg From owner-freebsd-net@FreeBSD.ORG Thu Aug 24 17:30:04 2006 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4DB1C16A4DA; Thu, 24 Aug 2006 17:30:04 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8914643D6E; Thu, 24 Aug 2006 17:29:52 +0000 (GMT) (envelope-from davidch@broadcom.com) Received: from 10.10.64.154 by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Thu, 24 Aug 2006 10:29:34 -0700 X-Server-Uuid: D9EB6F12-1469-4C1C-87A2-5E4C0D6F9D06 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id CDC252AF; Thu, 24 Aug 2006 10:29:33 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id A7CA92AE; Thu, 24 Aug 2006 10:29:33 -0700 (PDT) Received: from mail-irva-12.broadcom.com (mail-irva-12.broadcom.com [10.10.64.146]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id EDN91999; Thu, 24 Aug 2006 10:29:33 -0700 (PDT) Received: from NT-IRVA-0750.brcm.ad.broadcom.com (nt-irva-0750 [10.8.194.64]) by mail-irva-12.broadcom.com (Postfix) with ESMTP id 1ADED69CA4; Thu, 24 Aug 2006 10:29:33 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 24 Aug 2006 10:29:32 -0700 Message-ID: <09BFF2FA5EAB4A45B6655E151BBDD90301D4325E@NT-IRVA-0750.brcm.ad.broadcom.com> In-Reply-To: <20060824060922.GF76666@cell.sick.ru> Thread-Topic: bge(4) one packet wedge Thread-Index: AcbHQ+JYQw09H0cDRmOvlMC97kUp9AAXePaw From: "David Christensen" To: "Gleb Smirnoff" X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006082406; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413031303230342E34344544453045422E303033382D422D466E61662B777136512B6F5752675750386F344B49513D3D; ENG=IBF; TS=20060824172944; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006082406_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 68F33E743881745258-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: brad@openbsd.org, oleg@FreeBSD.org, net@FreeBSD.org Subject: RE: bge(4) one packet wedge 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, 24 Aug 2006 17:30:04 -0000 > D> This "lost interrupt" type of problem is addressed by the=20 > use of the > D> status_tag=20 > D> field in the status block. (Listed as bge_rsvd0 in the=20 > bge_status_block > D> structure).=20 > D> Everytime the status block is updated a new tag value is=20 > written to the > D> status block. =20 > D> When the ISR starts the driver should record the=20 > status_tag value. At > D> the end > D> of the ISR, the driver should compare the current=20 > status_tag value is > D> the status > D> block with the value recorded on entry to the ISR. If the=20 > values are > D> the same > D> then no additional status block updates have occurred so=20 > there shouldn't > D> be > D> any packets hanging around. If the values are different=20 > then additional > D> packets > D> or completions are waiting around so the ISR should loop=20 > around again. > D> At the=20 > D> end of the ISR the driver will write the status_tag value it last > D> handled to a > D> mailbox register, letting the hardware know the last=20 > status block update > D> handled. > D> If necessary the hardware will generate a new interrupt=20 > and start the > D> process over > D> again. > D>=20 > D> This entire process should be included in the Linux=20 > driver, I don't see > D> it being > D> used in the bge driver (bge_intr()). >=20 > True, this isn't done in FreeBSD driver. First I started to=20 > work on this, > but just noticed that I am seeing this problem on 5700 chip, that is > known not to support the status tag. >=20 > What can be the problem for not updated status block in the 5700 case? In general the problem isn't that the status block isn't being updated, but that the status update occurs AFTER the ISR has stopped looking at the status block, but before the ISR has re-enabled interrupts, thus missing the update. That's why tagged status mode is an improvement, the ISR actively tells the hardware which status block update it last processed and forces the hardware to generate another interrupt if a status block update was missed by the ISR. Dave From owner-freebsd-net@FreeBSD.ORG Thu Aug 24 17:36:38 2006 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4413A16A4DF; Thu, 24 Aug 2006 17:36:38 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id B013543D49; Thu, 24 Aug 2006 17:36:32 +0000 (GMT) (envelope-from davidch@broadcom.com) Received: from 10.10.64.154 by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Thu, 24 Aug 2006 10:36:17 -0700 X-Server-Uuid: D9EB6F12-1469-4C1C-87A2-5E4C0D6F9D06 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 6A43B2AF; Thu, 24 Aug 2006 10:36:17 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 444B52AE; Thu, 24 Aug 2006 10:36:17 -0700 (PDT) Received: from mail-irva-12.broadcom.com (mail-irva-12.broadcom.com [10.10.64.146]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id EDN93093; Thu, 24 Aug 2006 10:36:17 -0700 (PDT) Received: from NT-IRVA-0750.brcm.ad.broadcom.com (nt-irva-0750 [10.8.194.64]) by mail-irva-12.broadcom.com (Postfix) with ESMTP id EEB3A69CA3; Thu, 24 Aug 2006 10:36:16 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 24 Aug 2006 10:36:17 -0700 Message-ID: <09BFF2FA5EAB4A45B6655E151BBDD90301D43265@NT-IRVA-0750.brcm.ad.broadcom.com> In-Reply-To: <20060824075253.GH76666@cell.sick.ru> Thread-Topic: bge(4) one packet wedge Thread-Index: AcbHUlhNeGOZxoDJR+iqP9PqN7O7KQAUJPCA From: "David Christensen" To: "Gleb Smirnoff" X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006082406; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413031303230352E34344544453237372E303030342D422D466E61662B777136512B6F5752675750386F344B49513D3D; ENG=IBF; TS=20060824173619; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006082406_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 68F33C1B3881746646-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: brad@openbsd.org, oleg@FreeBSD.org, net@FreeBSD.org Subject: RE: bge(4) one packet wedge 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, 24 Aug 2006 17:36:38 -0000 > On Wed, Aug 23, 2006 at 12:53:49PM -0700, David Christensen wrote: > D> This "lost interrupt" type of problem is addressed by the=20 > use of the > D> status_tag=20 > D> field in the status block. (Listed as bge_rsvd0 in the=20 > bge_status_block > D> structure).=20 > D> Everytime the status block is updated a new tag value is=20 > written to the > D> status block. =20 > D> When the ISR starts the driver should record the=20 > status_tag value. At > D> the end > D> of the ISR, the driver should compare the current=20 > status_tag value is > D> the status > D> block with the value recorded on entry to the ISR. If the=20 > values are > D> the same > D> then no additional status block updates have occurred so=20 > there shouldn't > D> be > D> any packets hanging around. If the values are different=20 > then additional > D> packets > D> or completions are waiting around so the ISR should loop=20 > around again. > D> At the=20 > D> end of the ISR the driver will write the status_tag value it last > D> handled to a > D> mailbox register, letting the hardware know the last=20 > status block update > D> handled. > D> If necessary the hardware will generate a new interrupt=20 > and start the > D> process over > D> again. > D>=20 > D> This entire process should be included in the Linux=20 > driver, I don't see > D> it being > D> used in the bge driver (bge_intr()). >=20 > In the Linux driver for the not tag capable controllers there=20 > is a following > comment and code: >=20 > /* In INTx mode, it is possible for the interrupt to arrive at > * the CPU before the status block posted prior to=20 > the interrupt. > * Reading the PCI State register will confirm whether the > * interrupt is ours and will flush the status block. > */ > if ((sblk->status & SD_STATUS_UPDATED) || > !(tr32(TG3PCI_PCISTATE) & PCISTATE_INT_NOT_ACTIVE)) { >=20 > So, I tried to add (void)pci_read_config(sc->bge_dev,=20 > BGE_PCI_PCISTATE, 4) > to the bge_intr(). Unfortunately, this didn't help. >=20 This fix is really designed to handle bridges that haven't posted the status block memory write ahead of the PCI interrupt and I wouldn't expect it to=20 resolve the reported problem. A better solution would be to try and minimize the time between the last status block check and the time the interrupt is re-enabled. Unfortunately I don't think the problem can be completely eliminated with even the most creative coding solutions but I'd be happy to be proven wrong. Dave From owner-freebsd-net@FreeBSD.ORG Thu Aug 24 17:48:08 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8CFF816A4E6; Thu, 24 Aug 2006 17:48:08 +0000 (UTC) (envelope-from patl@volant.org) Received: from smtp.volant.org (gate.volant.org [207.111.218.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 833D843D5D; Thu, 24 Aug 2006 17:47:56 +0000 (GMT) (envelope-from patl@volant.org) Received: from adsl-065-081-071-131.sip.gnv.bellsouth.net ([65.81.71.131] helo=[192.168.1.121]) by smtp.volant.org with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34 (FreeBSD)) id 1GGJMF-000Nhd-RE; Thu, 24 Aug 2006 10:51:21 -0700 Date: Thu, 24 Aug 2006 10:46:50 -0400 From: Pat Lashley To: Fredrik Lindberg Message-ID: <93381966E13B960D4ACFF05C@garrett.local> In-Reply-To: <44EDCEC2.7060109@shapeshifter.se> References: <44E9F991.7020309@shapeshifter.se> <44EA1926.2000501@shapeshifter.se> <9C04919EE684029A410DE208@garrett.local> <44EAC40E.9000904@shapeshifter.se> <3E654CC0217F90E20FCD806E@garrett.local> <44EC90B7.6090908@shapeshifter.se> <44ECB0F2.9040300@FreeBSD.org> <44ECBB61.9020808@shapeshifter.se> <5D7785ADC030FEBFB9A5E69D@garrett.local> <44ED8266.1060303@shapeshifter.se> <7C6CDF1CB0BC58A6ADE1FCA8@garrett.local> <44EDCEC2.7060109@shapeshifter.se> X-Mailer: Mulberry/4.0.0 (Mac OS X) MIME-Version: 1.0 X-Scan-Signature: ad3247664fb21905dd1e193a1aebee8942160683 X-Spam-User: nobody X-Spam-Score: -2.5 (--) X-Spam-Score-Int: -24 X-Spam-Report: This mail has matched the spam-filter tests listed below. See http://spamassassin.org/tag/ for details about the specific tests reported. In general, the higher the number of total points, the more likely that it actually is spam. (The 'required' number of points listed below is the arbitrary number above which the message is normally considered spam.) Content analysis details: (-2.5 points total, 5.0 required) 0.1 HTML_MESSAGE BODY: HTML included in message 0.1 HTML_FONTCOLOR_RED BODY: HTML font color is red -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.4 DATE_IN_PAST_03_06 Date: is 3 to 6 hours before Received: date 1.8 AWL AWL: Auto-whitelist adjustment Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, Doug Barton Subject: Re: Zeroconfig and Multicast DNS 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, 24 Aug 2006 17:48:08 -0000 > I guess it's just my nature, I really don't want to restrict end users > ability to do stuff when there is no TECHNICAL limitation of doing so. > It's the classical policy versus mechanism scenario, imho policy should > be left to the user, of course provided with sane default values that > can be used out of the box. In general, I agree with, and have been known to strongly champion, that sentiment. But I also believe that programs should Do The Right Thing even when the config file is missing. And in this case The Right Thing is to advertise the hostname; since that will be the desired result in 99+% of the cases. > > Things get a bit more complex for multi-homed hosts; especially if they > > are connected to more than one local link using IPv4 Link Local > > Addressing... > > Well, I already have a proof-of-concept of this running a multi-homed > responder and hosts on both ends resolve the addresses correct. > > A multi-homed host with two interfaces configured in 169.254/16 will > have other major problems beyond mDNS as the host would threat > both interfaces as being on the same net even if they are > physically separated. And that's one of the things that we'll have to fix if we want LLA and mDNS to work correctly. The default should probably be to assume that they are separate; but to recognize if they are in fact on the same link. That should be easy enough to do since the LLA packets sent out on one interface will be seen by the other one when they are on the same link. > > As I mentioned in an earlier posting, I would really like to see it > > support multiple TLDs for a single host. In particular, if I'm using > > example.com, then mumble.local and mumble.example.com should both > > resolve via mDNS to the IP address of host mumble. Similarly, services > > advertised by host mumble should automatically be listed in both domains. > > Well, $(hostname).example.com. A $(ifaddr) :) > You would have to configure the NSS module to allow .com queries too. The NSS module shouldn't have to know which domains mDNS is handling. It should just attempt to resolve the FQDN given, using mDNS. If it fails, resolution will fall back to the next module listed in nsswitch.conf. (I envision the default as being: files mdns dns) The problem with your proposal is that if the config file is missing, there is no host advertisement at all. Also, that doesn't address the service advertisement records. As I recall, the actual DNS records for service discovery look something like _service._protocol.fqdn. So in the multi-domain situation, you want each service to be -automatically- advertised as existing in -all- of the host's domains. > > If we're going to require an entry in a config file to get address > > advertisement; then we need to ensure that the default config file Does > > The Right Thing for the 99.99% case. (Otherwise, it isn't really > > zeroconf, is it?) > > Of course, default configuration should always be such that it requires > none or minimal work by the end user to get it running with values > that suite most people. However I feel power-users shouldn't be > restricted to do what ever they want, even how crazy other people > might think it is. I think our main point of disagreement here is on whether suitable default behavior requires the presence of a (default) config file. With a minor disagreement over how much of the configuration should be choosable via /etc/rc.conf -vs- mdns.conf. > The default of my proof-of-concept stuff had this as default, which > means advertise a A and a PTR record for my hostname on all interfaces > using the address of the interface. (should be expanded with AAAA and > $(ifaddr6) in a real application). > > interface * { > $(hostname).local. A $(ifaddr) > $(ifaddr) PTR $(hostname).local. > } Adding IPv6 support wouldn't be quite as simple as just adding two more lines. The default behavior needs to be able to handle all three cases: IPv4 only, IPv6 only, and both. You don't want to advertise an A record if $(ifaddr) isn't set. (And you do NOT want to issue an error/warning message. At least not unless higher-than-default verbosity was explicitly requested.) > > I think that it would be best if the most common cases worked correctly > > without a config file at all. Command-line flags set via /etc/rc.conf > > can indicate interfaces that are (not) to be used, whether or not to > > automatically produce an HINFO record, and whether to advertise all > > (except 127/8) or none of the /etc/hosts records. Doing this via rc.conf > > makes it much easier to set up common options at install time via > > sysinstall. > > I really don't understand how it should read /etc/hosts, users might > have aliases in there that doesn't belong to them which would make > the responder announce records that doesn't belong to them. That's why the default should be to NOT advertise everything that is in /etc/hosts. But it would be very convenient to not have to add/remove the same mapping to two different config files. Please note that I'm not saying that you shouldn't be able to add mappings directly to the mdns.conf; only that if you are putting things into /etc/hosts anyway, it might be useful to have the ability to just tell mdns to advertise everything in /etc/hosts. > I was under the impression that resolv.conf was explicitly used by the > dns nss module, but I could be wrong. The mDNS will requires its own > nss module that should be independent from the other DNS. Hmmm. You may be right about who is reading resolv.conf. But I'm not really happy about the thought of adding yet another config file; especially since some of the info (domain/search) is almost certain to need to be duplicated between them. Since we need some way to tell the mdns daemon which domain(s) to use if we're using anything other than $(domainname); perhaps the mdns.conf can be shared between the daemon and the nss module. Split the info into sections to make it easier for each to know which parts they aren't expected to understand and put all of the stuff they both want into a shared section. -Pat From owner-freebsd-net@FreeBSD.ORG Thu Aug 24 17:56:10 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 25D3B16A4DA; Thu, 24 Aug 2006 17:56:10 +0000 (UTC) (envelope-from patl@volant.org) Received: from smtp.volant.org (gate.volant.org [207.111.218.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E4CE43D45; Thu, 24 Aug 2006 17:56:09 +0000 (GMT) (envelope-from patl@volant.org) Received: from adsl-065-081-071-131.sip.gnv.bellsouth.net ([65.81.71.131] helo=[192.168.1.121]) by smtp.volant.org with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34 (FreeBSD)) id 1GGJUG-000Nko-Rj; Thu, 24 Aug 2006 10:59:32 -0700 Date: Thu, 24 Aug 2006 10:55:15 -0400 From: Pat Lashley To: Fredrik Lindberg Message-ID: <0EC404BA0CA363942D250766@garrett.local> In-Reply-To: <44EDDB8C.9090504@shapeshifter.se> References: <44EA1926.2000501@shapeshifter.se> <9C04919EE684029A410DE208@garrett.local> <44EAC40E.9000904@shapeshifter.se> <3E654CC0217F90E20FCD806E@garrett.local> <44EC90B7.6090908@shapeshifter.se> <44ECB0F2.9040300@FreeBSD.org> <20060823212110.GD27961@lor.one-eyed-alien.net> <20060823221835.GA28978@lor.one-eyed-alien.net> <23D2619F6BACE4E728178EE5@garrett.local> <44ED3BD1.3030206@shapeshifter.se> <44EDA9A5.2050108@shapeshifter.se> <44EDBDD0.4050000@shapeshifter.se> <7CC9AC69410B69EBD31122E4@garrett.local> <44EDDB8C.9090504@shapeshifter.se> X-Mailer: Mulberry/4.0.0 (Mac OS X) MIME-Version: 1.0 X-Scan-Signature: 5a15c5ea388ea90143f439612b97eda4b14aa29c X-Spam-User: nobody X-Spam-Score: -2.5 (--) X-Spam-Score-Int: -24 X-Spam-Report: This mail has matched the spam-filter tests listed below. See http://spamassassin.org/tag/ for details about the specific tests reported. In general, the higher the number of total points, the more likely that it actually is spam. (The 'required' number of points listed below is the arbitrary number above which the message is normally considered spam.) Content analysis details: (-2.5 points total, 5.0 required) 0.1 HTML_MESSAGE BODY: HTML included in message 0.1 HTML_FONTCOLOR_RED BODY: HTML font color is red -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.4 DATE_IN_PAST_03_06 Date: is 3 to 6 hours before Received: date 1.8 AWL AWL: Auto-whitelist adjustment Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, Doug Barton Subject: Re: Zeroconfig and Multicast DNS 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, 24 Aug 2006 17:56:10 -0000 > If you want to communicate with an LLA host, fine, obtain an LLA > address otherwise take a hike. I'd make that '..., obtain an LLA address, or figure out how to do it via ARP, otherwise...' > My LLA implementation already does this..it never removes an address > from a interface it didn't set itself, and it always sets address > as aliases. That already makes it one step better than the Linux implementation I was working with last year... > There is also an option to force it to assign > (as an alias) a LLA address even if the interface is already is > configured with another address. I think that I'd reverse the default on that. There should normally be no harm in having an LLA address, as long as we've got the non-LLA preference stuff working correctly. It is quite likely that the LLA address would never actually be used; but so what? -Pat From owner-freebsd-net@FreeBSD.ORG Thu Aug 24 18:26:48 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F3D3A16A4DE; Thu, 24 Aug 2006 18:26:47 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from sccmmhc91.asp.att.net (sccmmhc91.asp.att.net [204.127.203.211]) by mx1.FreeBSD.org (Postfix) with ESMTP id 52EFB43D55; Thu, 24 Aug 2006 18:26:46 +0000 (GMT) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net ([12.207.12.9]) by sccmmhc91.asp.att.net (sccmmhc91) with ESMTP id <20060824182645m910087irae>; Thu, 24 Aug 2006 18:26:45 +0000 Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.13.6/8.13.6) with ESMTP id k7OIQgbC038232; Thu, 24 Aug 2006 13:26:42 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.13.6/8.13.6/Submit) id k7OIQeq1038231; Thu, 24 Aug 2006 13:26:40 -0500 (CDT) (envelope-from brooks) Date: Thu, 24 Aug 2006 13:26:40 -0500 From: Brooks Davis To: Pat Lashley Message-ID: <20060824182640.GA37561@lor.one-eyed-alien.net> References: <20060823221835.GA28978@lor.one-eyed-alien.net> <23D2619F6BACE4E728178EE5@garrett.local> <44ED3BD1.3030206@shapeshifter.se> <44EDA9A5.2050108@shapeshifter.se> <44EDBDD0.4050000@shapeshifter.se> <7CC9AC69410B69EBD31122E4@garrett.local> <44EDDB8C.9090504@shapeshifter.se> <0EC404BA0CA363942D250766@garrett.local> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LZvS9be/3tNcYl/X" Content-Disposition: inline In-Reply-To: <0EC404BA0CA363942D250766@garrett.local> User-Agent: Mutt/1.5.11 Cc: freebsd-net@freebsd.org, Doug Barton , Fredrik Lindberg Subject: Re: Zeroconfig and Multicast DNS 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, 24 Aug 2006 18:26:48 -0000 --LZvS9be/3tNcYl/X Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 24, 2006 at 10:55:15AM -0400, Pat Lashley wrote: > >If you want to communicate with an LLA host, fine, obtain an LLA > >address otherwise take a hike. >=20 > I'd make that '..., obtain an LLA address, or figure out how to do it via= =20 > ARP, otherwise...' >=20 > >My LLA implementation already does this..it never removes an address > >from a interface it didn't set itself, and it always sets address > >as aliases. >=20 > That already makes it one step better than the Linux implementation I was= =20 > working with last year... >=20 > > There is also an option to force it to assign > >(as an alias) a LLA address even if the interface is already is > >configured with another address. >=20 > I think that I'd reverse the default on that. There should normally be no= =20 > harm in having an LLA address, as long as we've got the non-LLA preferenc= e=20 > stuff working correctly. It is quite likely that the LLA address would=20 > never actually be used; but so what? Unless we modify the IPv4 routing code to actually know that different interfaces with LLAs are on different subnets, we will need to insure that there is only one interface with an LLA on it at once. The modification probably makes sense, but I have no idea what it would entail. -- Brooks --LZvS9be/3tNcYl/X Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFE7e9fXY6L6fI4GtQRAgVeAJkBV08nqh7McHrQ71JRSTvLXsyLhQCfX2hz VDT8nhRZOcxnCWFvWWoiJDc= =Rw36 -----END PGP SIGNATURE----- --LZvS9be/3tNcYl/X-- From owner-freebsd-net@FreeBSD.ORG Thu Aug 24 18:32:04 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5B54C16A4DD; Thu, 24 Aug 2006 18:32:04 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from sccmmhc91.asp.att.net (sccmmhc91.asp.att.net [204.127.203.211]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A63843D5C; Thu, 24 Aug 2006 18:32:01 +0000 (GMT) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net ([12.207.12.9]) by sccmmhc91.asp.att.net (sccmmhc91) with ESMTP id <20060824183159m91008790le>; Thu, 24 Aug 2006 18:31:59 +0000 Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.13.6/8.13.6) with ESMTP id k7OIVkLx038298; Thu, 24 Aug 2006 13:31:48 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.13.6/8.13.6/Submit) id k7OIVT4U038297; Thu, 24 Aug 2006 13:31:29 -0500 (CDT) (envelope-from brooks) Date: Thu, 24 Aug 2006 13:31:29 -0500 From: Brooks Davis To: Pat Lashley Message-ID: <20060824183129.GB37561@lor.one-eyed-alien.net> References: <44EAC40E.9000904@shapeshifter.se> <3E654CC0217F90E20FCD806E@garrett.local> <44EC90B7.6090908@shapeshifter.se> <44ECB0F2.9040300@FreeBSD.org> <44ECBB61.9020808@shapeshifter.se> <5D7785ADC030FEBFB9A5E69D@garrett.local> <44ED8266.1060303@shapeshifter.se> <7C6CDF1CB0BC58A6ADE1FCA8@garrett.local> <44EDCEC2.7060109@shapeshifter.se> <93381966E13B960D4ACFF05C@garrett.local> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gatW/ieO32f1wygP" Content-Disposition: inline In-Reply-To: <93381966E13B960D4ACFF05C@garrett.local> User-Agent: Mutt/1.5.11 Cc: freebsd-net@freebsd.org, Doug Barton , Fredrik Lindberg Subject: Re: Zeroconfig and Multicast DNS 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, 24 Aug 2006 18:32:04 -0000 --gatW/ieO32f1wygP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 24, 2006 at 10:46:50AM -0400, Pat Lashley wrote: > >> As I mentioned in an earlier posting, I would really like to see it > >> support multiple TLDs for a single host. In particular, if I'm using > >> example.com, then mumble.local and mumble.example.com should both > >> resolve via mDNS to the IP address of host mumble. Similarly, services > >> advertised by host mumble should automatically be listed in both domai= ns. > > > >Well, $(hostname).example.com. A $(ifaddr) :) > >You would have to configure the NSS module to allow .com queries too. >=20 > The NSS module shouldn't have to know which domains mDNS is handling. It= =20 > should just attempt to resolve the FQDN given, using mDNS. If it fails,= =20 > resolution will fall back to the next module listed in nsswitch.conf. (I= =20 > envision the default as being: files mdns dns) I don't know that you really want to trust random hosts to advertise addresses in arbitrary domains. That makes man in the middle attacks a little too easy. -- Brooks --gatW/ieO32f1wygP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFE7fCAXY6L6fI4GtQRApGkAJ427xN7rSTZ0gdTALUgtPpco8az4gCeKO/l ZsM6fX2UDSEh5n4Tbg3dmpA= =+PHY -----END PGP SIGNATURE----- --gatW/ieO32f1wygP-- From owner-freebsd-net@FreeBSD.ORG Thu Aug 24 18:34:15 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8B10116A4DA; Thu, 24 Aug 2006 18:34:15 +0000 (UTC) (envelope-from fli+freebsd-net@shapeshifter.se) Received: from mx1.h3q.net (manticore.shapeshifter.se [212.37.5.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 22FC243D73; Thu, 24 Aug 2006 18:34:03 +0000 (GMT) (envelope-from fli+freebsd-net@shapeshifter.se) Received: from localhost (localhost [127.0.0.1]) by mx1.h3q.net (Postfix) with ESMTP id DB75F1A78D; Thu, 24 Aug 2006 20:34:01 +0200 (CEST) Received: from mx1.h3q.net ([127.0.0.1]) by localhost (mx1.h3q.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 33232-04; Thu, 24 Aug 2006 20:34:00 +0200 (CEST) Received: from [192.168.1.100] (81-233-243-100-no50.tbcn.telia.com [81.233.243.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.h3q.net (Postfix) with ESMTP id 0D0F41A751; Thu, 24 Aug 2006 20:33:59 +0200 (CEST) Message-ID: <44EDF116.9050106@shapeshifter.se> Date: Thu, 24 Aug 2006 20:33:58 +0200 From: Fredrik Lindberg User-Agent: Thunderbird 1.5.0.4 (X11/20060727) MIME-Version: 1.0 To: Pat Lashley References: <44E9F991.7020309@shapeshifter.se> <44EA1926.2000501@shapeshifter.se> <9C04919EE684029A410DE208@garrett.local> <44EAC40E.9000904@shapeshifter.se> <3E654CC0217F90E20FCD806E@garrett.local> <44EC90B7.6090908@shapeshifter.se> <44ECB0F2.9040300@FreeBSD.org> <44ECBB61.9020808@shapeshifter.se> <5D7785ADC030FEBFB9A5E69D@garrett.local> <44ED8266.1060303@shapeshifter.se> <7C6CDF1CB0BC58A6ADE1FCA8@garrett.local> <44EDCEC2.7060109@shapeshifter.se> <93381966E13B960D4ACFF05C@garrett.local> In-Reply-To: <93381966E13B960D4ACFF05C@garrett.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at h3q.net Cc: freebsd-net@freebsd.org, Doug Barton Subject: Re: Zeroconfig and Multicast DNS 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, 24 Aug 2006 18:34:15 -0000 Pat Lashley wrote: >> I guess it's just my nature, I really don't want to restrict end users >> ability to do stuff when there is no TECHNICAL limitation of doing so. >> It's the classical policy versus mechanism scenario, imho policy should >> be left to the user, of course provided with sane default values that >> can be used out of the box. > > In general, I agree with, and have been known to strongly champion, that > sentiment. But I also believe that programs should Do The Right Thing > even when the config file is missing. And in this case The Right Thing > is to advertise the hostname; since that will be the desired result in > 99+% of the cases. Ah, ok, ok. Let's say our responder has the ability to parse a mdns.conf and if that file is missing then I very much agree > >> > Things get a bit more complex for multi-homed hosts; especially if they >> > are connected to more than one local link using IPv4 Link Local >> > Addressing... >> >> Well, I already have a proof-of-concept of this running a multi-homed >> responder and hosts on both ends resolve the addresses correct. >> >> A multi-homed host with two interfaces configured in 169.254/16 will >> have other major problems beyond mDNS as the host would threat >> both interfaces as being on the same net even if they are >> physically separated. > > And that's one of the things that we'll have to fix if we want LLA and > mDNS to work correctly. The default should probably be to assume that > they are separate; but to recognize if they are in fact on the same > link. That should be easy enough to do since the LLA packets sent out on > one interface will be seen by the other one when they are on the same link. > Um...I'm not sure if this is even possible. Let's forget mDNS and go back to basic IP. Say a multi-homed host has two interfaces both configured with an address in the rage 169.254/16, say 169.254.1.1 and 169.254.2.1 and it wants to initiate a connection to 169.254.3.1, how on earth should it be able to tell on which side 3.1 is located? There might even be one 3.1 on both side that could be completely different hosts. >> > As I mentioned in an earlier posting, I would really like to see it >> > support multiple TLDs for a single host. In particular, if I'm using >> > example.com, then mumble.local and mumble.example.com should both >> > resolve via mDNS to the IP address of host mumble. Similarly, services >> > advertised by host mumble should automatically be listed in both >> domains. >> Ok, some kind of alias that will propagate for all records. I don't have a good solution to it yet, I need to think about this but I do get your point (and I can see the benefit with it). >> Well, $(hostname).example.com. A $(ifaddr) :) >> You would have to configure the NSS module to allow .com queries too. > > The NSS module shouldn't have to know which domains mDNS is handling. It > should just attempt to resolve the FQDN given, using mDNS. If it fails, > resolution will fall back to the next module listed in nsswitch.conf. (I > envision the default as being: files mdns dns) This suggestion is VERY VERY dangerous. Any responder on the network could very well decide to respond to for example www.google.com (or to the address of your internet banking site). What you see in your browser would be www.google.com and the page might look like google but you won't be at the site you think. Having the responder resolve names with real TLDs means that it will resolve names that it does not have the authority over. The nsswitch.conf should IHMO be :files dns mdns, and the mdns nss module should ship with a default to only allow queries to .local .168.254.in-addr.arpa .168.192.in-addr.arpa .16.172.in-addr.arpa-31.172.in-addr.arpa .10.in-addr.arpa And whatever set of IPs that are assign as link/site-local for IPv6, I don't remember them at the moment. However it should be possible for a user to add whatever TLD he/she wants or disable the restriction all together. But the default should be restricted to prevent name spoofs. > > The problem with your proposal is that if the config file is missing, > there is no host advertisement at all. Also, that doesn't address the > service advertisement records. As I recall, the actual DNS records for > service discovery look something like _service._protocol.fqdn. So in the > multi-domain situation, you want each service to be -automatically- > advertised as existing in -all- of the host's domains. > >> > If we're going to require an entry in a config file to get address >> > advertisement; then we need to ensure that the default config file Does >> > The Right Thing for the 99.99% case. (Otherwise, it isn't really >> > zeroconf, is it?) >> >> Of course, default configuration should always be such that it requires >> none or minimal work by the end user to get it running with values >> that suite most people. However I feel power-users shouldn't be >> restricted to do what ever they want, even how crazy other people >> might think it is. > > I think our main point of disagreement here is on whether suitable > default behavior requires the presence of a (default) config file. With > a minor disagreement over how much of the configuration should be > choosable via /etc/rc.conf -vs- mdns.conf. > Ok, so if no mdns.conf is available then the responder will attempt to register hostname.local (and a ptr record), but if a mdns.conf IS available it takes precedence over the default behavior. I think I can go along with that. >> The default of my proof-of-concept stuff had this as default, which >> means advertise a A and a PTR record for my hostname on all interfaces >> using the address of the interface. (should be expanded with AAAA and >> $(ifaddr6) in a real application). >> >> interface * { >> $(hostname).local. A $(ifaddr) >> $(ifaddr) PTR $(hostname).local. >> } > > Adding IPv6 support wouldn't be quite as simple as just adding two more > lines. The default behavior needs to be able to handle all three cases: > IPv4 only, IPv6 only, and both. You don't want to advertise an A record > if $(ifaddr) isn't set. (And you do NOT want to issue an error/warning > message. At least not unless higher-than-default verbosity was > explicitly requested.) Of course, of course. If no data is available for a record, that record would not be used. (This is more or less implementation details). > >> > I think that it would be best if the most common cases worked correctly >> > without a config file at all. Command-line flags set via /etc/rc.conf >> > can indicate interfaces that are (not) to be used, whether or not to >> > automatically produce an HINFO record, and whether to advertise all >> > (except 127/8) or none of the /etc/hosts records. Doing this via >> rc.conf >> > makes it much easier to set up common options at install time via >> > sysinstall. >> >> I really don't understand how it should read /etc/hosts, users might >> have aliases in there that doesn't belong to them which would make >> the responder announce records that doesn't belong to them. > > That's why the default should be to NOT advertise everything that is in > /etc/hosts. But it would be very convenient to not have to add/remove > the same mapping to two different config files. > > Please note that I'm not saying that you shouldn't be able to add > mappings directly to the mdns.conf; only that if you are putting things > into /etc/hosts anyway, it might be useful to have the ability to just > tell mdns to advertise everything in /etc/hosts. Hmm..I'm not sure, but as long as it's not default behavior it's just another way of adding records. And users might find it handy so I guess it would be a possible option. > >> I was under the impression that resolv.conf was explicitly used by the >> dns nss module, but I could be wrong. The mDNS will requires its own >> nss module that should be independent from the other DNS. > > Hmmm. You may be right about who is reading resolv.conf. But I'm not > really happy about the thought of adding yet another config file; > especially since some of the info (domain/search) is almost certain to > need to be duplicated between them. > > Since we need some way to tell the mdns daemon which domain(s) to use if > we're using anything other than $(domainname); perhaps the mdns.conf can > be shared between the daemon and the nss module. Split the info into > sections to make it easier for each to know which parts they aren't > expected to understand and put all of the stuff they both want into a > shared section. > Yes, that's certainly a possibility and will reduce the number of configuration files. Fredrik Lindberg From owner-freebsd-net@FreeBSD.ORG Thu Aug 24 18:40:12 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7DC7116A4DA; Thu, 24 Aug 2006 18:40:12 +0000 (UTC) (envelope-from fli+freebsd-net@shapeshifter.se) Received: from mx1.h3q.net (manticore.shapeshifter.se [212.37.5.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id BF7D343D45; Thu, 24 Aug 2006 18:40:11 +0000 (GMT) (envelope-from fli+freebsd-net@shapeshifter.se) Received: from localhost (localhost [127.0.0.1]) by mx1.h3q.net (Postfix) with ESMTP id DEEFD1A78D; Thu, 24 Aug 2006 20:40:10 +0200 (CEST) Received: from mx1.h3q.net ([127.0.0.1]) by localhost (mx1.h3q.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 33232-06; Thu, 24 Aug 2006 20:40:10 +0200 (CEST) Received: from [192.168.1.100] (81-233-243-100-no50.tbcn.telia.com [81.233.243.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.h3q.net (Postfix) with ESMTP id A52DB1A751; Thu, 24 Aug 2006 20:40:09 +0200 (CEST) Message-ID: <44EDF289.1090309@shapeshifter.se> Date: Thu, 24 Aug 2006 20:40:09 +0200 From: Fredrik Lindberg User-Agent: Thunderbird 1.5.0.4 (X11/20060727) MIME-Version: 1.0 To: Pat Lashley References: <44EA1926.2000501@shapeshifter.se> <9C04919EE684029A410DE208@garrett.local> <44EAC40E.9000904@shapeshifter.se> <3E654CC0217F90E20FCD806E@garrett.local> <44EC90B7.6090908@shapeshifter.se> <44ECB0F2.9040300@FreeBSD.org> <20060823212110.GD27961@lor.one-eyed-alien.net> <20060823221835.GA28978@lor.one-eyed-alien.net> <23D2619F6BACE4E728178EE5@garrett.local> <44ED3BD1.3030206@shapeshifter.se> <44EDA9A5.2050108@shapeshifter.se> <44EDBDD0.4050000@shapeshifter.se> <7CC9AC69410B69EBD31122E4@garrett.local> <44EDDB8C.9090504@shapeshifter.se> <0EC404BA0CA363942D250766@garrett.local> In-Reply-To: <0EC404BA0CA363942D250766@garrett.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at h3q.net Cc: freebsd-net@freebsd.org, Doug Barton Subject: Re: Zeroconfig and Multicast DNS 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, 24 Aug 2006 18:40:12 -0000 Pat Lashley wrote: > > I think that I'd reverse the default on that. There should normally be > no harm in having an LLA address, as long as we've got the non-LLA > preference stuff working correctly. It is quite likely that the LLA > address would never actually be used; but so what? > I've been thinking about that too, but I'm still not sure. The RFC says that you shouldn't add a LLA address to an interface that already is configured with a routeable address. Configuring LLA via rc.conf should probably be done like DHCP, by using a magic word in the ifconfig_ifX-line. We could have two words, one called LLA that would run in the "forced" mode and another LLA2 (I can't come up a good name) which would run in the RFC compliant way. Fredrik Lindberg From owner-freebsd-net@FreeBSD.ORG Thu Aug 24 18:42:43 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BE80216A4DD; Thu, 24 Aug 2006 18:42:43 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from sccmmhc92.asp.att.net (sccmmhc92.asp.att.net [204.127.203.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8158943D69; Thu, 24 Aug 2006 18:42:38 +0000 (GMT) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net ([12.207.12.9]) by sccmmhc92.asp.att.net (sccmmhc92) with ESMTP id <20060824184236m92002th3fe>; Thu, 24 Aug 2006 18:42:37 +0000 Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.13.6/8.13.6) with ESMTP id k7OIgYbD038442; Thu, 24 Aug 2006 13:42:34 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.13.6/8.13.6/Submit) id k7OIgXbN038441; Thu, 24 Aug 2006 13:42:33 -0500 (CDT) (envelope-from brooks) Date: Thu, 24 Aug 2006 13:42:29 -0500 From: Brooks Davis To: Fredrik Lindberg Message-ID: <20060824184228.GC37561@lor.one-eyed-alien.net> References: <3E654CC0217F90E20FCD806E@garrett.local> <44EC90B7.6090908@shapeshifter.se> <44ECB0F2.9040300@FreeBSD.org> <44ECBB61.9020808@shapeshifter.se> <5D7785ADC030FEBFB9A5E69D@garrett.local> <44ED8266.1060303@shapeshifter.se> <7C6CDF1CB0BC58A6ADE1FCA8@garrett.local> <44EDCEC2.7060109@shapeshifter.se> <93381966E13B960D4ACFF05C@garrett.local> <44EDF116.9050106@shapeshifter.se> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Y5rl02BVI9TCfPar" Content-Disposition: inline In-Reply-To: <44EDF116.9050106@shapeshifter.se> User-Agent: Mutt/1.5.11 Cc: freebsd-net@freebsd.org, Pat Lashley , Doug Barton Subject: Re: Zeroconfig and Multicast DNS 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, 24 Aug 2006 18:42:43 -0000 --Y5rl02BVI9TCfPar Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 24, 2006 at 08:33:58PM +0200, Fredrik Lindberg wrote: > Pat Lashley wrote: > >>> Things get a bit more complex for multi-homed hosts; especially if th= ey > >>> are connected to more than one local link using IPv4 Link Local > >>> Addressing... > >> > >>Well, I already have a proof-of-concept of this running a multi-homed > >>responder and hosts on both ends resolve the addresses correct. > >> > >>A multi-homed host with two interfaces configured in 169.254/16 will > >>have other major problems beyond mDNS as the host would threat > >>both interfaces as being on the same net even if they are > >>physically separated. > > > >And that's one of the things that we'll have to fix if we want LLA and= =20 > >mDNS to work correctly. The default should probably be to assume that=20 > >they are separate; but to recognize if they are in fact on the same=20 > >link. That should be easy enough to do since the LLA packets sent out on= =20 > >one interface will be seen by the other one when they are on the same li= nk. > > >=20 > Um...I'm not sure if this is even possible. Let's forget mDNS and > go back to basic IP. > Say a multi-homed host has two interfaces both configured with an > address in the rage 169.254/16, say 169.254.1.1 and 169.254.2.1 and > it wants to initiate a connection to 169.254.3.1, how on earth should > it be able to tell on which side 3.1 is located? There might even be > one 3.1 on both side that could be completely different hosts. You probably would need an extension similiar to the one for IPv6 LLAs. i.e. the %bge0 in fe80::2e0:81ff:fe31:9f00%bge0. > >>> As I mentioned in an earlier posting, I would really like to see it > >>> support multiple TLDs for a single host. In particular, if I'm using > >>> example.com, then mumble.local and mumble.example.com should both > >>> resolve via mDNS to the IP address of host mumble. Similarly, services > >>> advertised by host mumble should automatically be listed in both=20 > >>domains. > >> >=20 > Ok, some kind of alias that will propagate for all records. I don't > have a good solution to it yet, I need to think about this but I do > get your point (and I can see the benefit with it). >=20 > >>Well, $(hostname).example.com. A $(ifaddr) :) > >>You would have to configure the NSS module to allow .com queries too. > > > >The NSS module shouldn't have to know which domains mDNS is handling. It= =20 > >should just attempt to resolve the FQDN given, using mDNS. If it fails,= =20 > >resolution will fall back to the next module listed in nsswitch.conf. (I= =20 > >envision the default as being: files mdns dns) >=20 > This suggestion is VERY VERY dangerous. Any responder on the network > could very well decide to respond to for example www.google.com (or to > the address of your internet banking site). What you see in your browser > would be www.google.com and the page might look like google but you > won't be at the site you think. Having the responder resolve names > with real TLDs means that it will resolve names that it does not have > the authority over. >=20 > The nsswitch.conf should IHMO be :files dns mdns, and the mdns nss > module should ship with a default to only allow queries to > .local > .168.254.in-addr.arpa > .168.192.in-addr.arpa > .16.172.in-addr.arpa-31.172.in-addr.arpa > .10.in-addr.arpa >=20 > And whatever set of IPs that are assign as link/site-local for IPv6, > I don't remember them at the moment. > However it should be possible for a user to add whatever TLD he/she > wants or disable the restriction all together. But the default should > be restricted to prevent name spoofs. Agreed. In most environments a spoof will still be possible, but it would be harder and would require traffic that is detectable by a good IDS. -- Brooks -- Brooks --Y5rl02BVI9TCfPar Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFE7fMUXY6L6fI4GtQRAiAAAJwM7/H/dmHGVThi4Fy2q2Vx5AaAyQCgmFWp A5VSFgjMEUgMNpgfYUqY/gw= =PBA+ -----END PGP SIGNATURE----- --Y5rl02BVI9TCfPar-- From owner-freebsd-net@FreeBSD.ORG Thu Aug 24 18:45:37 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9C56816A4DF; Thu, 24 Aug 2006 18:45:37 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from sccmmhc91.asp.att.net (sccmmhc91.asp.att.net [204.127.203.211]) by mx1.FreeBSD.org (Postfix) with ESMTP id EF46A43D45; Thu, 24 Aug 2006 18:45:36 +0000 (GMT) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net ([12.207.12.9]) by sccmmhc91.asp.att.net (sccmmhc91) with ESMTP id <20060824184536m910086jple>; Thu, 24 Aug 2006 18:45:36 +0000 Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.13.6/8.13.6) with ESMTP id k7OIjXgq038525; Thu, 24 Aug 2006 13:45:34 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.13.6/8.13.6/Submit) id k7OIjR01038516; Thu, 24 Aug 2006 13:45:27 -0500 (CDT) (envelope-from brooks) Date: Thu, 24 Aug 2006 13:45:17 -0500 From: Brooks Davis To: Fredrik Lindberg Message-ID: <20060824184517.GD37561@lor.one-eyed-alien.net> References: <23D2619F6BACE4E728178EE5@garrett.local> <44ED3BD1.3030206@shapeshifter.se> <44EDA9A5.2050108@shapeshifter.se> <44EDBDD0.4050000@shapeshifter.se> <7CC9AC69410B69EBD31122E4@garrett.local> <44EDDB8C.9090504@shapeshifter.se> <0EC404BA0CA363942D250766@garrett.local> <44EDF289.1090309@shapeshifter.se> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="48TaNjbzBVislYPb" Content-Disposition: inline In-Reply-To: <44EDF289.1090309@shapeshifter.se> User-Agent: Mutt/1.5.11 Cc: freebsd-net@freebsd.org, Pat Lashley , Doug Barton Subject: Re: Zeroconfig and Multicast DNS 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, 24 Aug 2006 18:45:37 -0000 --48TaNjbzBVislYPb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 24, 2006 at 08:40:09PM +0200, Fredrik Lindberg wrote: > Pat Lashley wrote: > > > >I think that I'd reverse the default on that. There should normally be= =20 > >no harm in having an LLA address, as long as we've got the non-LLA=20 > >preference stuff working correctly. It is quite likely that the LLA=20 > >address would never actually be used; but so what? > > >=20 > I've been thinking about that too, but I'm still not sure. The RFC > says that you shouldn't add a LLA address to an interface that > already is configured with a routeable address. >=20 > Configuring LLA via rc.conf should probably be done like DHCP, by > using a magic word in the ifconfig_ifX-line. > We could have two words, one called LLA that would run in the "forced" > mode and another LLA2 (I can't come up a good name) which would run > in the RFC compliant way. Configuring in compliant mode is going to be hard with our current setup. To be honest, I'm not terriably worried about it. The bigger issue in my mind is that we need to deal one way or another with multihomed hosts. An a side note, the magic option should probably contain the number 4 in it somewhere to differentiate it from other forms of LLA. -- Brooks --48TaNjbzBVislYPb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFE7fO8XY6L6fI4GtQRAgwkAKDOTCfsn9tep0p8Se+2u6TN+dDTrQCeLe8u sTvtImN1bJyGyuKBMq2/6/U= =oSLo -----END PGP SIGNATURE----- --48TaNjbzBVislYPb-- From owner-freebsd-net@FreeBSD.ORG Thu Aug 24 18:51:11 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 22DE416A4DA for ; Thu, 24 Aug 2006 18:51:11 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx24.fluidhosting.com [204.14.89.7]) by mx1.FreeBSD.org (Postfix) with SMTP id 6C9FA43D45 for ; Thu, 24 Aug 2006 18:51:10 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 19216 invoked by uid 399); 24 Aug 2006 18:51:10 -0000 Received: from localhost (HELO ?192.168.0.3?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 24 Aug 2006 18:51:10 -0000 Message-ID: <44EDF51B.3010701@FreeBSD.org> Date: Thu, 24 Aug 2006 11:51:07 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 1.5.0.5 (X11/20060729) MIME-Version: 1.0 To: Fredrik Lindberg References: <44EA1926.2000501@shapeshifter.se> <9C04919EE684029A410DE208@garrett.local> <44EAC40E.9000904@shapeshifter.se> <3E654CC0217F90E20FCD806E@garrett.local> <44EC90B7.6090908@shapeshifter.se> <44ECB0F2.9040300@FreeBSD.org> <20060823212110.GD27961@lor.one-eyed-alien.net> <20060823221835.GA28978@lor.one-eyed-alien.net> <23D2619F6BACE4E728178EE5@garrett.local> <44ED3BD1.3030206@shapeshifter.se> <44EDA9A5.2050108@shapeshifter.se> <44EDBDD0.4050000@shapeshifter.se> <7CC9AC69410B69EBD31122E4@garrett.local> <44EDDB8C.9090504@shapeshifter.se> <0EC404BA0CA363942D250766@garrett.local> <44EDF289.1090309@shapeshifter.se> In-Reply-To: <44EDF289.1090309@shapeshifter.se> X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Pat Lashley Subject: Re: Zeroconfig and Multicast DNS 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, 24 Aug 2006 18:51:11 -0000 Fredrik Lindberg wrote: > I've been thinking about that too, but I'm still not sure. The RFC > says . . . Which RFC(s)? :) My read is that there are several that are relevant, generally, to LLA and mDNS, so it would be useful to know precisely what we're discussing. Which reminds me, that's something I left off of my last post, which is a request for any documentation that people feel it's important to be up to speed on for this topic, including the relevant RFCs. And in the meantime, this has been a very good discussion, keep it up! Doug -- This .signature sanitized for your protection From owner-freebsd-net@FreeBSD.ORG Thu Aug 24 18:55:18 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C936916A4DA for ; Thu, 24 Aug 2006 18:55:18 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx24.fluidhosting.com [204.14.89.7]) by mx1.FreeBSD.org (Postfix) with SMTP id EB1C743D45 for ; Thu, 24 Aug 2006 18:55:17 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 24420 invoked by uid 399); 24 Aug 2006 18:55:17 -0000 Received: from localhost (HELO ?192.168.0.3?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 24 Aug 2006 18:55:17 -0000 Message-ID: <44EDF613.8080605@FreeBSD.org> Date: Thu, 24 Aug 2006 11:55:15 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 1.5.0.5 (X11/20060729) MIME-Version: 1.0 To: Brooks Davis References: <3E654CC0217F90E20FCD806E@garrett.local> <44EC90B7.6090908@shapeshifter.se> <44ECB0F2.9040300@FreeBSD.org> <44ECBB61.9020808@shapeshifter.se> <5D7785ADC030FEBFB9A5E69D@garrett.local> <44ED8266.1060303@shapeshifter.se> <7C6CDF1CB0BC58A6ADE1FCA8@garrett.local> <44EDCEC2.7060109@shapeshifter.se> <93381966E13B960D4ACFF05C@garrett.local> <44EDF116.9050106@shapeshifter.se> <20060824184228.GC37561@lor.one-eyed-alien.net> In-Reply-To: <20060824184228.GC37561@lor.one-eyed-alien.net> X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Pat Lashley , Fredrik Lindberg Subject: Re: Zeroconfig and Multicast DNS 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, 24 Aug 2006 18:55:18 -0000 Brooks Davis wrote: > On Thu, Aug 24, 2006 at 08:33:58PM +0200, Fredrik Lindberg wrote: >> The nsswitch.conf should IHMO be :files dns mdns, and the mdns nss >> module should ship with a default to only allow queries to >> .local >> .168.254.in-addr.arpa >> .168.192.in-addr.arpa >> .16.172.in-addr.arpa-31.172.in-addr.arpa >> .10.in-addr.arpa >> >> And whatever set of IPs that are assign as link/site-local for IPv6, >> I don't remember them at the moment. >> However it should be possible for a user to add whatever TLD he/she >> wants or disable the restriction all together. But the default should >> be restricted to prevent name spoofs. > > Agreed. In most environments a spoof will still be possible, but it > would be harder and would require traffic that is detectable by a good > IDS. Me too. :) The chief objection to mDNS (and other p2p types of dns services) is the possibility of making it easier to hijack "real" websites. I do not object (off hand) to a mechanism to define additional hostnames to announce other than your own, but I think that we should do something like unconditionally append .local to them to make sure that we're not creating a bigger problem than we're solving. Doug -- This .signature sanitized for your protection From owner-freebsd-net@FreeBSD.ORG Thu Aug 24 19:01:40 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2B95516A4DD; Thu, 24 Aug 2006 19:01:40 +0000 (UTC) (envelope-from fli+freebsd-net@shapeshifter.se) Received: from mx1.h3q.net (manticore.shapeshifter.se [212.37.5.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 87C1443D45; Thu, 24 Aug 2006 19:01:39 +0000 (GMT) (envelope-from fli+freebsd-net@shapeshifter.se) Received: from localhost (localhost [127.0.0.1]) by mx1.h3q.net (Postfix) with ESMTP id 5AC121A78D; Thu, 24 Aug 2006 21:01:38 +0200 (CEST) Received: from mx1.h3q.net ([127.0.0.1]) by localhost (mx1.h3q.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 33568-02; Thu, 24 Aug 2006 21:01:37 +0200 (CEST) Received: from [192.168.1.100] (81-233-243-100-no50.tbcn.telia.com [81.233.243.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.h3q.net (Postfix) with ESMTP id 243A21A751; Thu, 24 Aug 2006 21:01:37 +0200 (CEST) Message-ID: <44EDF790.5020105@shapeshifter.se> Date: Thu, 24 Aug 2006 21:01:36 +0200 From: Fredrik Lindberg User-Agent: Thunderbird 1.5.0.4 (X11/20060727) MIME-Version: 1.0 To: Doug Barton References: <44EA1926.2000501@shapeshifter.se> <9C04919EE684029A410DE208@garrett.local> <44EAC40E.9000904@shapeshifter.se> <3E654CC0217F90E20FCD806E@garrett.local> <44EC90B7.6090908@shapeshifter.se> <44ECB0F2.9040300@FreeBSD.org> <20060823212110.GD27961@lor.one-eyed-alien.net> <20060823221835.GA28978@lor.one-eyed-alien.net> <23D2619F6BACE4E728178EE5@garrett.local> <44ED3BD1.3030206@shapeshifter.se> <44EDA9A5.2050108@shapeshifter.se> <44EDBDD0.4050000@shapeshifter.se> <7CC9AC69410B69EBD31122E4@garrett.local> <44EDDB8C.9090504@shapeshifter.se> <0EC404BA0CA363942D250766@garrett.local> <44EDF289.1090309@shapeshifter.se> <44EDF51B.3010701@FreeBSD.org> In-Reply-To: <44EDF51B.3010701@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at h3q.net Cc: freebsd-net@freebsd.org, Pat Lashley Subject: Re: Zeroconfig and Multicast DNS 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, 24 Aug 2006 19:01:40 -0000 Doug Barton wrote: > Fredrik Lindberg wrote: > >> I've been thinking about that too, but I'm still not sure. The RFC >> says . . . > > Which RFC(s)? :) My read is that there are several that are relevant, > generally, to LLA and mDNS, so it would be useful to know precisely what > we're discussing. Sorry, we're discussing everything at once :) This particular post was about LLA. > > Which reminds me, that's something I left off of my last post, which is a > request for any documentation that people feel it's important to be up to > speed on for this topic, including the relevant RFCs. > http://www.zeroconf.org/ http://files.zeroconf.org/rfc3927.txt - IPv4 Link-local addressing http://www.multicastdns.org/ http://files.multicastdns.org/draft-cheshire-dnsext-multicastdns.txt http://www.dns-sd.org/ http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt Fredrik Lindberg From owner-freebsd-net@FreeBSD.ORG Thu Aug 24 19:22:14 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 659C616A4E0; Thu, 24 Aug 2006 19:22:14 +0000 (UTC) (envelope-from patl+freebsd@volant.org) Received: from smtp.volant.org (gate.volant.org [207.111.218.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 82C5B43D69; Thu, 24 Aug 2006 19:21:30 +0000 (GMT) (envelope-from patl+freebsd@volant.org) Received: from adsl-065-081-071-131.sip.gnv.bellsouth.net ([65.81.71.131] helo=[192.168.1.121]) by smtp.volant.org with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34 (FreeBSD)) id 1GGKot-000ObU-4l; Thu, 24 Aug 2006 12:24:54 -0700 Date: Thu, 24 Aug 2006 12:20:39 -0400 From: Pat Lashley To: Brooks Davis Message-ID: In-Reply-To: <20060824182640.GA37561@lor.one-eyed-alien.net> References: <20060823221835.GA28978@lor.one-eyed-alien.net> <23D2619F6BACE4E728178EE5@garrett.local> <44ED3BD1.3030206@shapeshifter.se> <44EDA9A5.2050108@shapeshifter.se> <44EDBDD0.4050000@shapeshifter.se> <7CC9AC69410B69EBD31122E4@garrett.local> <44EDDB8C.9090504@shapeshifter.se> <0EC404BA0CA363942D250766@garrett.local> <20060824182640.GA37561@lor.one-eyed-alien.net> X-Mailer: Mulberry/4.0.0 (Mac OS X) MIME-Version: 1.0 X-Scan-Signature: 5caa3080e9e177639d5e90d9ec1e125ab59782a9 X-Spam-User: nobody X-Spam-Score: -4.1 (----) X-Spam-Score-Int: -40 X-Spam-Report: This mail has matched the spam-filter tests listed below. See http://spamassassin.org/tag/ for details about the specific tests reported. In general, the higher the number of total points, the more likely that it actually is spam. (The 'required' number of points listed below is the arbitrary number above which the message is normally considered spam.) Content analysis details: (-4.1 points total, 5.0 required) 0.1 HTML_MESSAGE BODY: HTML included in message 0.1 HTML_FONTCOLOR_RED BODY: HTML font color is red -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.4 DATE_IN_PAST_03_06 Date: is 3 to 6 hours before Received: date 0.2 AWL AWL: Auto-whitelist adjustment Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, Doug Barton , Fredrik Lindberg Subject: Re: Zeroconfig and Multicast DNS 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, 24 Aug 2006 19:22:14 -0000 > > > There is also an option to force it to assign > > >(as an alias) a LLA address even if the interface is already is > > >configured with another address. > > > > I think that I'd reverse the default on that. There should normally be no > > harm in having an LLA address, as long as we've got the non-LLA preference > > stuff working correctly. It is quite likely that the LLA address would > > never actually be used; but so what? > > Unless we modify the IPv4 routing code to actually know that different > interfaces with LLAs are on different subnets, we will need to insure > that there is only one interface with an LLA on it at once. The > modification probably makes sense, but I have no idea what it would > entail. Actually, it is quite possible for multiple interfaces to be on the same LLA link/subnet; so we can't make any assumptions either way. We -do- need to be able to handle the case where they are on different links. That really isn't an 'unless', it's a 'when'. We also need to be able to handle the case where they are on physically different links; but the host is acting as a bridge between them to make one logical link sharing a single LLA subnet. (We don't need to explicitly handle the case where the bridging is being handled externally because that should be virtually indistinguishable from a single physical link.) Our lla daemon should be tracking -all- LLA ARP requests/responses on the interfaces on which it is active. So, over time, the system will normally collect a fairly complete set of IP address <-> MAC mappings for each interface. There's no reason why the lla daemon shouldn't add those mappings to the routing table as it discovers them. (And remove them if they time out...) And that should make it easy to detect which interfaces are on the same link. So the issue mainly arises with the case where we want to open a connection to a host/service for which we have a mapping to an LLA IP address; but no mapping to a MAC address. In that case, I think we need to send an ARP request on each distinct local link for which we are using LLA. If there are multiple interfaces connected to that link, we can choose one arbitrarily. I think this all means that for a multi-homed host, we should not automatically add a route for the 169.254/16 network. Instead, we should just add specific /32s as discovered; and use ARP when we need to find a new 169.254.x.y -> MAC translation. There still remains the possibility of multiple distinct hosts having the same LLA IP address on separate local links; each attached to a separate interface. In practice that situation should be sufficiently rare that we can afford to ignore it until someone comes up with some clever way to handle it. (Or we all move to IPv6 and it becomes moot.) -Pat From owner-freebsd-net@FreeBSD.ORG Thu Aug 24 19:31:39 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6EBB216A4DE; Thu, 24 Aug 2006 19:31:39 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from sccmmhc91.asp.att.net (sccmmhc91.asp.att.net [204.127.203.211]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6272943D6D; Thu, 24 Aug 2006 19:31:37 +0000 (GMT) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net ([12.207.12.9]) by sccmmhc91.asp.att.net (sccmmhc91) with ESMTP id <20060824193136m910086029e>; Thu, 24 Aug 2006 19:31:36 +0000 Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.13.6/8.13.6) with ESMTP id k7OJVU1B038970; Thu, 24 Aug 2006 14:31:32 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.13.6/8.13.6/Submit) id k7OJVSke038969; Thu, 24 Aug 2006 14:31:28 -0500 (CDT) (envelope-from brooks) Date: Thu, 24 Aug 2006 14:31:27 -0500 From: Brooks Davis To: Pat Lashley Message-ID: <20060824193127.GA38855@lor.one-eyed-alien.net> References: <44ED3BD1.3030206@shapeshifter.se> <44EDA9A5.2050108@shapeshifter.se> <44EDBDD0.4050000@shapeshifter.se> <7CC9AC69410B69EBD31122E4@garrett.local> <44EDDB8C.9090504@shapeshifter.se> <0EC404BA0CA363942D250766@garrett.local> <20060824182640.GA37561@lor.one-eyed-alien.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UugvWAfsgieZRqgk" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11 Cc: freebsd-net@freebsd.org, Doug Barton , Fredrik Lindberg Subject: Re: Zeroconfig and Multicast DNS 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, 24 Aug 2006 19:31:39 -0000 --UugvWAfsgieZRqgk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 24, 2006 at 12:20:39PM -0400, Pat Lashley wrote: > >> > There is also an option to force it to assign > >> >(as an alias) a LLA address even if the interface is already is > >> >configured with another address. > >> > >> I think that I'd reverse the default on that. There should normally be= no > >> harm in having an LLA address, as long as we've got the non-LLA=20 > >preference > >> stuff working correctly. It is quite likely that the LLA address would > >> never actually be used; but so what? > > > >Unless we modify the IPv4 routing code to actually know that different > >interfaces with LLAs are on different subnets, we will need to insure > >that there is only one interface with an LLA on it at once. The > >modification probably makes sense, but I have no idea what it would > >entail. >=20 > Actually, it is quite possible for multiple interfaces to be on the same= =20 > LLA link/subnet; so we can't make any assumptions either way. We -do- ne= ed=20 > to be able to handle the case where they are on different links. That=20 > really isn't an 'unless', it's a 'when'. I can't see how it's worth worrying about the case they are on the same network. I'm pretty sure that if you act as though they are on separate networks things will work just as well weather they are or not. > We also need to be able to handle the case where they are on physically= =20 > different links; but the host is acting as a bridge between them to make= =20 > one logical link sharing a single LLA subnet. (We don't need to explicit= ly=20 > handle the case where the bridging is being handled externally because th= at=20 > should be virtually indistinguishable from a single physical link.) If there's a bridge (only considering if_bridge here) then the bridge interface should have the LLA. Configuring LLAs on the physical interfaces would be wrong and isn't worth supporting. > Our lla daemon should be tracking -all- LLA ARP requests/responses on the= =20 > interfaces on which it is active. So, over time, the system will normall= y=20 > collect a fairly complete set of IP address <-> MAC mappings for each=20 > interface. There's no reason why the lla daemon shouldn't add those=20 > mappings to the routing table as it discovers them. (And remove them if= =20 > they time out...) And that should make it easy to detect which interfaces= =20 > are on the same link. > > > So the issue mainly arises with the case where we want to open a connecti= on=20 > to a host/service for which we have a mapping to an LLA IP address; but n= o=20 > mapping to a MAC address. In that case, I think we need to send an ARP= =20 > request on each distinct local link for which we are using LLA. If there= =20 > are multiple interfaces connected to that link, we can choose one=20 > arbitrarily. >=20 > I think this all means that for a multi-homed host, we should not=20 > automatically add a route for the 169.254/16 network. Instead, we should= =20 > just add specific /32s as discovered; and use ARP when we need to find a= =20 > new 169.254.x.y -> MAC translation. > > > There still remains the possibility of multiple distinct hosts having the= =20 > same LLA IP address on separate local links; each attached to a separate= =20 > interface. In practice that situation should be sufficiently rare that we= =20 > can afford to ignore it until someone comes up with some clever way to=20 > handle it. (Or we all move to IPv6 and it becomes moot.) The right way to deal with this is almost certainly to adopt the KAME %interface decoration for link local addresses. LLAs are meaningless outside the context of an interface. Unless you only have one interface with an LLA, you must know which interface you are addressing to know where to send the packet. While you can hack around this in some cases by trying all of them and hoping there aren't any collisions, I think that's the wrong way to go. -- Brooks --UugvWAfsgieZRqgk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFE7f6OXY6L6fI4GtQRAtbdAJ9jY+HfPBQM/1A/Mz4P82Ipui+9KgCg1u0O RCzusjwe/eHD6r1lVMnuRyk= =0zeh -----END PGP SIGNATURE----- --UugvWAfsgieZRqgk-- From owner-freebsd-net@FreeBSD.ORG Thu Aug 24 19:39:38 2006 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0FC3816A4E6; Thu, 24 Aug 2006 19:39:38 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 45AAE43D55; Thu, 24 Aug 2006 19:39:35 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.4/8.13.3) with ESMTP id k7OJdTgb085889 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Aug 2006 23:39:29 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.4/8.13.1/Submit) id k7OJdTMk085888; Thu, 24 Aug 2006 23:39:29 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 24 Aug 2006 23:39:28 +0400 From: Gleb Smirnoff To: David Christensen Message-ID: <20060824193928.GP76666@cell.sick.ru> References: <20060824060922.GF76666@cell.sick.ru> <09BFF2FA5EAB4A45B6655E151BBDD90301D4325E@NT-IRVA-0750.brcm.ad.broadcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <09BFF2FA5EAB4A45B6655E151BBDD90301D4325E@NT-IRVA-0750.brcm.ad.broadcom.com> User-Agent: Mutt/1.5.6i Cc: brad@openbsd.org, oleg@FreeBSD.org, net@FreeBSD.org Subject: Re: bge(4) one packet wedge 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, 24 Aug 2006 19:39:38 -0000 David, On Thu, Aug 24, 2006 at 10:29:32AM -0700, David Christensen wrote: D> In general the problem isn't that the status block isn't being updated, D> but that D> the status update occurs AFTER the ISR has stopped looking at the status D> block, but before the ISR has re-enabled interrupts, thus missing the D> update. D> That's why tagged status mode is an improvement, the ISR actively tells D> the D> hardware which status block update it last processed and forces the D> hardware D> to generate another interrupt if a status block update was missed by the D> ISR. My kgdb session shows that the status block is not updated later, after ISR, but isn't updated at all until next packet arrives! It looks like this: once netperf wedges, I run kgdb, find address of softc, look at status block, look that the ring index is the same as saved in softc. It takes a minute for me to type all these things. Status block isn't updated. Then I can look into the ring itself at the index+1 descriptor, and analyze the mbuf inside of it. This mbuf will be that one wedged packet! The packet I would see in tcpdump as soon as I send another one. Ok, can you please review the patch, I've sent earlier today, that utilizes the status block tag correctly? -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Thu Aug 24 20:00:36 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 527F116A4F2; Thu, 24 Aug 2006 20:00:36 +0000 (UTC) (envelope-from fli+freebsd-net@shapeshifter.se) Received: from mx1.h3q.net (manticore.shapeshifter.se [212.37.5.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0F0EE43D8E; Thu, 24 Aug 2006 20:00:13 +0000 (GMT) (envelope-from fli+freebsd-net@shapeshifter.se) Received: from localhost (localhost [127.0.0.1]) by mx1.h3q.net (Postfix) with ESMTP id A3AF61A78D; Thu, 24 Aug 2006 22:00:11 +0200 (CEST) Received: from mx1.h3q.net ([127.0.0.1]) by localhost (mx1.h3q.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 34223-03; Thu, 24 Aug 2006 22:00:11 +0200 (CEST) Received: from [192.168.1.100] (81-233-243-100-no50.tbcn.telia.com [81.233.243.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.h3q.net (Postfix) with ESMTP id DC3D11A751; Thu, 24 Aug 2006 22:00:08 +0200 (CEST) Message-ID: <44EE0548.4080503@shapeshifter.se> Date: Thu, 24 Aug 2006 22:00:08 +0200 From: Fredrik Lindberg User-Agent: Thunderbird 1.5.0.4 (X11/20060727) MIME-Version: 1.0 To: Brooks Davis References: <44ED3BD1.3030206@shapeshifter.se> <44EDA9A5.2050108@shapeshifter.se> <44EDBDD0.4050000@shapeshifter.se> <7CC9AC69410B69EBD31122E4@garrett.local> <44EDDB8C.9090504@shapeshifter.se> <0EC404BA0CA363942D250766@garrett.local> <20060824182640.GA37561@lor.one-eyed-alien.net> <20060824193127.GA38855@lor.one-eyed-alien.net> In-Reply-To: <20060824193127.GA38855@lor.one-eyed-alien.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at h3q.net Cc: freebsd-net@freebsd.org, Pat Lashley , Doug Barton Subject: Re: Zeroconfig and Multicast DNS 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, 24 Aug 2006 20:00:36 -0000 Brooks Davis wrote: > > The right way to deal with this is almost certainly to adopt the KAME > %interface decoration for link local addresses. LLAs are meaningless > outside the context of an interface. Unless you only have one interface > with an LLA, you must know which interface you are addressing to know > where to send the packet. While you can hack around this in some cases > by trying all of them and hoping there aren't any collisions, I think > that's the wrong way to go. > I don't know how familiar you are with the IPv6 code, but are you (or somebody else) able to estimate in a short summary what would be required to adopt the %interface decoration for IPv4? If it turns out to be a very large task, will it still be worth it? Fredrik Lindberg From owner-freebsd-net@FreeBSD.ORG Thu Aug 24 20:09:09 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BAC6F16A4E0; Thu, 24 Aug 2006 20:09:09 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from sccmmhc92.asp.att.net (sccmmhc92.asp.att.net [204.127.203.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F8C943D67; Thu, 24 Aug 2006 20:09:03 +0000 (GMT) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net ([12.207.12.9]) by sccmmhc92.asp.att.net (sccmmhc92) with ESMTP id <20060824200902m92002reqre>; Thu, 24 Aug 2006 20:09:02 +0000 Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.13.6/8.13.6) with ESMTP id k7OK8v7r039355; Thu, 24 Aug 2006 15:08:58 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.13.6/8.13.6/Submit) id k7OK8uWU039354; Thu, 24 Aug 2006 15:08:56 -0500 (CDT) (envelope-from brooks) Date: Thu, 24 Aug 2006 15:08:56 -0500 From: Brooks Davis To: Fredrik Lindberg Message-ID: <20060824200856.GB38855@lor.one-eyed-alien.net> References: <44EDA9A5.2050108@shapeshifter.se> <44EDBDD0.4050000@shapeshifter.se> <7CC9AC69410B69EBD31122E4@garrett.local> <44EDDB8C.9090504@shapeshifter.se> <0EC404BA0CA363942D250766@garrett.local> <20060824182640.GA37561@lor.one-eyed-alien.net> <20060824193127.GA38855@lor.one-eyed-alien.net> <44EE0548.4080503@shapeshifter.se> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pvezYHf7grwyp3Bc" Content-Disposition: inline In-Reply-To: <44EE0548.4080503@shapeshifter.se> User-Agent: Mutt/1.5.11 Cc: freebsd-net@freebsd.org, Pat Lashley , Doug Barton Subject: Re: Zeroconfig and Multicast DNS 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, 24 Aug 2006 20:09:09 -0000 --pvezYHf7grwyp3Bc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 24, 2006 at 10:00:08PM +0200, Fredrik Lindberg wrote: > Brooks Davis wrote: > > > >The right way to deal with this is almost certainly to adopt the KAME > >%interface decoration for link local addresses. LLAs are meaningless > >outside the context of an interface. Unless you only have one interface > >with an LLA, you must know which interface you are addressing to know > >where to send the packet. While you can hack around this in some cases > >by trying all of them and hoping there aren't any collisions, I think > >that's the wrong way to go. > > >=20 > I don't know how familiar you are with the IPv6 code, but are you (or > somebody else) able to estimate in a short summary what would be > required to adopt the %interface decoration for IPv4? > If it turns out to be a very large task, will it still be worth it? I don't know the details so it's something that would have to be investigated. My feeling is that if we want to deal with multiple interfaces with LLAs we're going to need to do some not-insignificant kernel and libc work to support them. It not clear to me how much overall work that will be and how worthwhile it is. -- Brooks --pvezYHf7grwyp3Bc Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFE7gdXXY6L6fI4GtQRAmaPAKDIeLyoMozCe3vYZ8X2A9AK65zkYQCgvZAB xaKvd4oKJYIZKGvA7DMQfUs= =+88U -----END PGP SIGNATURE----- --pvezYHf7grwyp3Bc-- From owner-freebsd-net@FreeBSD.ORG Thu Aug 24 20:59:52 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AA0A616A4DF; Thu, 24 Aug 2006 20:59:52 +0000 (UTC) (envelope-from patl@volant.org) Received: from smtp.volant.org (gate.volant.org [207.111.218.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id D410543D55; Thu, 24 Aug 2006 20:59:51 +0000 (GMT) (envelope-from patl@volant.org) Received: from adsl-065-081-071-131.sip.gnv.bellsouth.net ([65.81.71.131] helo=[192.168.1.121]) by smtp.volant.org with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34 (FreeBSD)) id 1GGMM3-000Pax-QM; Thu, 24 Aug 2006 14:03:14 -0700 Date: Thu, 24 Aug 2006 13:58:59 -0400 From: Pat Lashley To: Doug Barton , Brooks Davis Message-ID: <086CEFFE8D3417F3400FF7B8@garrett.local> X-Mailer: Mulberry/4.0.0 (Mac OS X) MIME-Version: 1.0 X-Scan-Signature: 6dcd5be253d6683eb8dedfe342e22c254fedadd7 X-Spam-User: nobody X-Spam-Score: -2.5 (--) X-Spam-Score-Int: -24 X-Spam-Report: This mail has matched the spam-filter tests listed below. See http://spamassassin.org/tag/ for details about the specific tests reported. In general, the higher the number of total points, the more likely that it actually is spam. (The 'required' number of points listed below is the arbitrary number above which the message is normally considered spam.) Content analysis details: (-2.5 points total, 5.0 required) 0.1 HTML_MESSAGE BODY: HTML included in message 0.1 HTML_FONTCOLOR_RED BODY: HTML font color is red -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0013] 0.4 DATE_IN_PAST_03_06 Date: is 3 to 6 hours before Received: date 1.8 AWL AWL: Auto-whitelist adjustment Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, Fredrik Lindberg Subject: Re: Zeroconfig and Multicast DNS 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, 24 Aug 2006 20:59:52 -0000 > Me too. :) The chief objection to mDNS (and other p2p types of dns > services) is the possibility of making it easier to hijack "real" websites. > I do not object (off hand) to a mechanism to define additional hostnames to > announce other than your own, but I think that we should do something like > unconditionally append .local to them to make sure that we're not creating a > bigger problem than we're solving. To do so, the hijacker would have to get onto your local link. For hardwired LANs, that shouldn't be a major issue. (If they're on your LAN, you're already screwed.) It's a much bigger problem for WiFi; especially when using a public access point. -Pat From owner-freebsd-net@FreeBSD.ORG Thu Aug 24 20:59:55 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4B0DD16A518; Thu, 24 Aug 2006 20:59:55 +0000 (UTC) (envelope-from patl+freebsd@volant.org) Received: from smtp.volant.org (gate.volant.org [207.111.218.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id BF2E843D53; Thu, 24 Aug 2006 20:59:54 +0000 (GMT) (envelope-from patl+freebsd@volant.org) Received: from adsl-065-081-071-131.sip.gnv.bellsouth.net ([65.81.71.131] helo=[192.168.1.121]) by smtp.volant.org with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34 (FreeBSD)) id 1GGMM8-000Pax-Cu; Thu, 24 Aug 2006 14:03:19 -0700 Date: Thu, 24 Aug 2006 13:59:10 -0400 From: Pat Lashley To: Fredrik Lindberg Message-ID: X-Mailer: Mulberry/4.0.0 (Mac OS X) MIME-Version: 1.0 X-Scan-Signature: 471fe4329b9bac1676f30a614122b72a46154b45 X-Spam-User: nobody X-Spam-Score: -4.1 (----) X-Spam-Score-Int: -40 X-Spam-Report: This mail has matched the spam-filter tests listed below. See http://spamassassin.org/tag/ for details about the specific tests reported. In general, the higher the number of total points, the more likely that it actually is spam. (The 'required' number of points listed below is the arbitrary number above which the message is normally considered spam.) Content analysis details: (-4.1 points total, 5.0 required) 0.1 HTML_MESSAGE BODY: HTML included in message 0.1 HTML_FONTCOLOR_RED BODY: HTML font color is red -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.4 DATE_IN_PAST_03_06 Date: is 3 to 6 hours before Received: date 0.1 AWL AWL: Auto-whitelist adjustment Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, Doug Barton Subject: Re: Zeroconfig and Multicast DNS 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, 24 Aug 2006 20:59:55 -0000 > > I think that I'd reverse the default on that. There should normally be > > no harm in having an LLA address, as long as we've got the non-LLA > > preference stuff working correctly. It is quite likely that the LLA > > address would never actually be used; but so what? > > > > I've been thinking about that too, but I'm still not sure. The RFC > says that you shouldn't add a LLA address to an interface that > already is configured with a routeable address. I think that you're referring to the first paragraph of section 1.9. That section appears to assume that some sort of ARP-based routing will be used by all parties to allow hosts with IP addresses in different (sub)nets to directly communicate if they are on the same segment. That section then goes on to specify when both a routable and an IPv4 Link-Local address MAY be assigned. Sub-paragraph 2 indicates that if a routable address is available on the interface, we MUST stop -advertising- the IPv4 Link-Local address (i.e., remove it from the mDNS records); but may keep (and defend) the address and accept new connections on it. Note that this only applies to IPv4. It doesn't say that we can't continue to advertise an IPv6 Link-Local address. (Which makes sense; since the point of the restriction is to reduce problems caused by dynamically changing IP addresses; and that won't happen with IPv6 Link-Local.) > Configuring LLA via rc.conf should probably be done like DHCP, by > using a magic word in the ifconfig_ifX-line. > > We could have two words, one called LLA that would run in the "forced" > mode and another LLA2 (I can't come up a good name) which would run > in the RFC compliant way. The problem with that is that we want to support the use of both on the same link. So we'd either need to allow more than one keyword, or have 'DHCP', 'LLA', 'LLA+DHCP', etc. Neither of those is very attractive. I think it would be cleaner to have something like: ipv4-link-local-always="bge* fxp1" ipv4-link-local-fallback="fxp0" -Pat From owner-freebsd-net@FreeBSD.ORG Thu Aug 24 21:00:03 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 893E016A521; Thu, 24 Aug 2006 21:00:03 +0000 (UTC) (envelope-from patl+freebsd@volant.org) Received: from smtp.volant.org (gate.volant.org [207.111.218.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 70AE043D4C; Thu, 24 Aug 2006 21:00:00 +0000 (GMT) (envelope-from patl+freebsd@volant.org) Received: from adsl-065-081-071-131.sip.gnv.bellsouth.net ([65.81.71.131] helo=[192.168.1.121]) by smtp.volant.org with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34 (FreeBSD)) id 1GGMMD-000Pax-4H; Thu, 24 Aug 2006 14:03:25 -0700 Date: Thu, 24 Aug 2006 13:59:17 -0400 From: Pat Lashley To: Fredrik Lindberg Message-ID: X-Mailer: Mulberry/4.0.0 (Mac OS X) MIME-Version: 1.0 X-Scan-Signature: f329dc5f5a799b32320295d1695d397a02150f27 X-Spam-User: nobody X-Spam-Score: -3.0 (---) X-Spam-Score-Int: -29 X-Spam-Report: This mail has matched the spam-filter tests listed below. See http://spamassassin.org/tag/ for details about the specific tests reported. In general, the higher the number of total points, the more likely that it actually is spam. (The 'required' number of points listed below is the arbitrary number above which the message is normally considered spam.) Content analysis details: (-3.0 points total, 5.0 required) 2.2 DOMAIN_BODY BODY: Domain registration spam body 0.1 HTML_MESSAGE BODY: HTML included in message 0.1 HTML_FONTCOLOR_RED BODY: HTML font color is red -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.4 DATE_IN_PAST_03_06 Date: is 3 to 6 hours before Received: date -1.0 AWL AWL: Auto-whitelist adjustment Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, Doug Barton Subject: Re: Zeroconfig and Multicast DNS 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, 24 Aug 2006 21:00:03 -0000 First, I'd like to correct something that slipped by earlier. Service Discovery via DNS does -NOT depend on mDNS; it may be implemented using traditional unicast DNS. (And to a pure client, there should be no detectable difference.) > > In general, I agree with, and have been known to strongly champion, that > > sentiment. But I also believe that programs should Do The Right Thing > > even when the config file is missing. And in this case The Right Thing > > is to advertise the hostname; since that will be the desired result in > > 99+% of the cases. > > Ah, ok, ok. Let's say our responder has the ability to parse a mdns.conf > and if that file is missing then I very much agree No, it shouldn't depend on whether the file is present or not. The defaults should be reasonable; and the config file should be able to override the defaults. You should -never- have to put anything in the config file to obtain behavior that would be chosen automatically if the config file were absent. It should be possible to explicitly specify behavior that matches the default; just for those of us who don't always trust the defaults not to change. But it shouldn't be necessary just because a config file exists. An empty, or comment-only config file should produce the same behavior as a missing one. A config file with one default behavior explicitly specified should also produce the same behavior as a missing config file, or one that explicitly specifies all of the options as matching the defaults. > > And that's one of the things that we'll have to fix if we want LLA and > > mDNS to work correctly. The default should probably be to assume that > > they are separate; but to recognize if they are in fact on the same > > link. That should be easy enough to do since the LLA packets sent out on > > one interface will be seen by the other one when they are on the same link. > > > > Um...I'm not sure if this is even possible. Let's forget mDNS and > go back to basic IP. > Say a multi-homed host has two interfaces both configured with an > address in the rage 169.254/16, say 169.254.1.1 and 169.254.2.1 and > it wants to initiate a connection to 169.254.3.1, how on earth should > it be able to tell on which side 3.1 is located? There might even be > one 3.1 on both side that could be completely different hosts. Yep, that's distinctly possible. BUT, remember, the 169.254/16 network can't really be sub-netted. So that situation would only occur if the interfaces are on separate 'local' links. My claim is that when the host does its initial 'I want to use this address' broadcast on interface 1, it should also -receive- that packet on interface 2 IFF the two are on the same link. It shouldn't have any trouble distinguishing its own request from some other host's request for the same IP address. (For one thing, it should know all of its own MAC addresses.) So it shouldn't be too hard to automatically determine whether its interfaces are on the same link or not. (It could do a simple same-physical-link check by trying to send an Ethernet packet from interface 1 to the MAC address for interface 2; but that may not handle all of the cases where there's an external bridge connecting two physical segments into one logical 'local link'. It would also require further adaptation for non-Ethernet interfaces. So recognizing its own RFC-3927 packets is probably the best way to go.) > >> > As I mentioned in an earlier posting, I would really like to see it > >> > support multiple TLDs for a single host. In particular, if I'm using > >> > example.com, then mumble.local and mumble.example.com should both > >> > resolve via mDNS to the IP address of host mumble. Similarly, services > >> > advertised by host mumble should automatically be listed in both > >> domains. > >> > > Ok, some kind of alias that will propagate for all records. I don't > have a good solution to it yet, I need to think about this but I do > get your point (and I can see the benefit with it). > > >> Well, $(hostname).example.com. A $(ifaddr) :) > >> You would have to configure the NSS module to allow .com queries too. > > > > The NSS module shouldn't have to know which domains mDNS is handling. It > > should just attempt to resolve the FQDN given, using mDNS. If it fails, > > resolution will fall back to the next module listed in nsswitch.conf. (I > > envision the default as being: files mdns dns) > > This suggestion is VERY VERY dangerous. Any responder on the network > could very well decide to respond to for example www.google.com (or to > the address of your internet banking site). What you see in your browser > would be www.google.com and the page might look like google but you > won't be at the site you think. Having the responder resolve names > with real TLDs means that it will resolve names that it does not have > the authority over. > > The nsswitch.conf should IHMO be :files dns mdns, > and the mdns nss module should ship with a default to only allow queries to > .local > .168.254.in-addr.arpa I think you meant .254.168.in-addr.arpa here. > .168.192.in-addr.arpa > .16.172.in-addr.arpa-31.172.in-addr.arpa > .10.in-addr.arpa I put mdns before dns for performance reasons. If you restrict the queries as defined above, there's no real advantage to doing the dns query first. I am reluctantly coming to agree that for security reasons we need to restrict the domains for A record lookups via mDNS; and PTR records in the in-addr.arpa domain. But service discovery will often have a non-.local domain; so I think we need to allow PTR/SVC/TXT lookups in any domain. (Or possibly anything outside in-addr.arpa. Given the existence of the .local domain, I don't see any utility in advertising a service in an in-addr.arpa domain. I'm sure somebody will post an example if I'm just being short-sighted here...) > And whatever set of IPs that are assign as link/site-local for IPv6, > I don't remember them at the moment. Isn't link-local the fe80:: network? I don't remember the site-local network ID; and it isn't automatically set; so I can't find it via 'ifconfig -u'. > However it should be possible for a user to add whatever TLD he/she > wants or disable the restriction all together. But the default should > be restricted to prevent name spoofs. Yes, I'm afraid you're right. > > I think our main point of disagreement here is on whether suitable > > default behavior requires the presence of a (default) config file. With > > a minor disagreement over how much of the configuration should be > > choosable via /etc/rc.conf -vs- mdns.conf. > > > > Ok, so if no mdns.conf is available then the responder will attempt > to register hostname.local (and a ptr record), but if a mdns.conf IS > available it takes precedence over the default behavior. > I think I can go along with that. No, if a mdns.conf file IS available, it will still register hostname.local (and the PTR record); UNLESS the mdns.conf explicitly asks it not to. Assuming, of course, that IPv4 is enabled on that interface. The mere presence of a config file should -NOT- alter default behavior. And the same goes for the AAAA record if IPv6 is enabled on the interface. > > Adding IPv6 support wouldn't be quite as simple as just adding two more > > lines. The default behavior needs to be able to handle all three cases: > > IPv4 only, IPv6 only, and both. You don't want to advertise an A record > > if $(ifaddr) isn't set. (And you do NOT want to issue an error/warning > > message. At least not unless higher-than-default verbosity was > > explicitly requested.) > > Of course, of course. If no data is available for a record, that record > would not be used. (This is more or less implementation details). Not entirely. It is also a syntactic/semantic issue in the config file design. There's a choice between whether there's an implicit "ignore this if the necessary protocol isn't available" or some sort of conditional block to explicitly say 'if condition X, then apply the following set of options'. The later is potentially more powerful. > > That's why the default should be to NOT advertise everything that is in > > /etc/hosts. But it would be very convenient to not have to add/remove > > the same mapping to two different config files. > > > > Please note that I'm not saying that you shouldn't be able to add > > mappings directly to the mdns.conf; only that if you are putting things > > into /etc/hosts anyway, it might be useful to have the ability to just > > tell mdns to advertise everything in /etc/hosts. > > Hmm..I'm not sure, but as long as it's not default behavior it's just > another way of adding records. And users might find it handy so I guess > it would be a possible option. That's my thought. I don't personally expect to use it; but I think it's useful enough to be readily available. -Pat From owner-freebsd-net@FreeBSD.ORG Thu Aug 24 21:37:56 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D6BE616A4E2; Thu, 24 Aug 2006 21:37:56 +0000 (UTC) (envelope-from patl@volant.org) Received: from smtp.volant.org (gate.volant.org [207.111.218.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id DEDCE43D53; Thu, 24 Aug 2006 21:37:55 +0000 (GMT) (envelope-from patl@volant.org) Received: from adsl-065-081-071-131.sip.gnv.bellsouth.net ([65.81.71.131] helo=[192.168.1.121]) by smtp.volant.org with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34 (FreeBSD)) id 1GGMwq-000Q0M-8O; Thu, 24 Aug 2006 14:41:18 -0700 Date: Thu, 24 Aug 2006 14:36:58 -0400 From: Pat Lashley To: Brooks Davis Message-ID: <806B67472BBA47707142E56E@garrett.local> In-Reply-To: <20060824193127.GA38855@lor.one-eyed-alien.net> References: <44ED3BD1.3030206@shapeshifter.se> <44EDA9A5.2050108@shapeshifter.se> <44EDBDD0.4050000@shapeshifter.se> <7CC9AC69410B69EBD31122E4@garrett.local> <44EDDB8C.9090504@shapeshifter.se> <0EC404BA0CA363942D250766@garrett.local> <20060824182640.GA37561@lor.one-eyed-alien.net> <20060824193127.GA38855@lor.one-eyed-alien.net> X-Mailer: Mulberry/4.0.0 (Mac OS X) MIME-Version: 1.0 X-Scan-Signature: 102bbe161560b8bf980e2de6e610da09758f22fd X-Spam-User: nobody X-Spam-Score: -2.5 (--) X-Spam-Score-Int: -24 X-Spam-Report: This mail has matched the spam-filter tests listed below. See http://spamassassin.org/tag/ for details about the specific tests reported. In general, the higher the number of total points, the more likely that it actually is spam. (The 'required' number of points listed below is the arbitrary number above which the message is normally considered spam.) Content analysis details: (-2.5 points total, 5.0 required) 0.1 HTML_MESSAGE BODY: HTML included in message 0.1 HTML_FONTCOLOR_RED BODY: HTML font color is red -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.4 DATE_IN_PAST_03_06 Date: is 3 to 6 hours before Received: date 1.8 AWL AWL: Auto-whitelist adjustment Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, Doug Barton , Fredrik Lindberg Subject: Re: Zeroconfig and Multicast DNS 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, 24 Aug 2006 21:37:57 -0000 > > Actually, it is quite possible for multiple interfaces to be on the same > > LLA link/subnet; so we can't make any assumptions either way. We -do- need > > to be able to handle the case where they are on different links. That > > really isn't an 'unless', it's a 'when'. > > I can't see how it's worth worrying about the case they are on the same > network. I'm pretty sure that if you act as though they are on separate > networks things will work just as well weather they are or not. I'd have to go dig through the RFCs. I suspect that it wouldn't make any difference to the normal interface usage; but might be significant to the LLA and/or mDNS protocol handling. And we most certainly don't want to allow bridging to be enabled between the interfaces if they -are- on the same segment. > > We also need to be able to handle the case where they are on physically > > different links; but the host is acting as a bridge between them to make > > one logical link sharing a single LLA subnet. (We don't need to explicitly > > handle the case where the bridging is being handled externally because that > > should be virtually indistinguishable from a single physical link.) > > If there's a bridge (only considering if_bridge here) then the bridge > interface should have the LLA. Configuring LLAs on the physical > interfaces would be wrong and isn't worth supporting. It's been a long time since I've set up a bridge; so I'm a bit rusty on all of the details. But from the if_bridge man page, it doesn't look like the bridge interface has an IP address of its own. (And I can't see why it would want one.) Also, I was using 'bridge' as a short-hand which would include any sort of proxying or routing that would make two physical segments operate as one local link for address negotiation. Overall, I don't really expect that to be a big issue; just one of those less common setups that we need to ensure does something reasonable by default. > The right way to deal with this is almost certainly to adopt the KAME > %interface decoration for link local addresses. LLAs are meaningless > outside the context of an interface. Unless you only have one interface > with an LLA, you must know which interface you are addressing to know > where to send the packet. While you can hack around this in some cases > by trying all of them and hoping there aren't any collisions, I think > that's the wrong way to go. Except in the case where multiple interfaces are on the same segment for redundancy. But in general, I suspect that you are right that using a %interface notation is the way to go. Now, how do we handle the problem in DNS-SD ? The service records just have a domain name. -Pat From owner-freebsd-net@FreeBSD.ORG Thu Aug 24 21:47:04 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A42DA16A509; Thu, 24 Aug 2006 21:47:04 +0000 (UTC) (envelope-from fli+freebsd-net@shapeshifter.se) Received: from mx1.h3q.net (manticore.shapeshifter.se [212.37.5.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id CF9DA43D49; Thu, 24 Aug 2006 21:46:54 +0000 (GMT) (envelope-from fli+freebsd-net@shapeshifter.se) Received: from localhost (localhost [127.0.0.1]) by mx1.h3q.net (Postfix) with ESMTP id AC3F41A78D; Thu, 24 Aug 2006 23:46:52 +0200 (CEST) Received: from mx1.h3q.net ([127.0.0.1]) by localhost (mx1.h3q.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 34359-09; Thu, 24 Aug 2006 23:46:49 +0200 (CEST) Received: from [192.168.1.100] (217-208-33-252-o926.tbon.telia.com [217.208.33.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.h3q.net (Postfix) with ESMTP id A1C861A72A; Thu, 24 Aug 2006 23:46:49 +0200 (CEST) Message-ID: <44EE1E48.6000006@shapeshifter.se> Date: Thu, 24 Aug 2006 23:46:48 +0200 From: Fredrik Lindberg User-Agent: Thunderbird 1.5.0.4 (X11/20060727) MIME-Version: 1.0 To: Pat Lashley References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at h3q.net Cc: freebsd-net@freebsd.org, Doug Barton Subject: Re: Zeroconfig and Multicast DNS 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, 24 Aug 2006 21:47:04 -0000 Pat Lashley wrote: > First, I'd like to correct something that slipped by earlier. Service > Discovery via DNS does -NOT depend on mDNS; it may be implemented using > traditional unicast DNS. (And to a pure client, there should be no > detectable difference.) > Yes this is correct (if I've implied otherwise it was a mistake). See below. > > No, it shouldn't depend on whether the file is present or not. The > defaults should be reasonable; and the config file should be able to > override the defaults. You should -never- have to put anything in the > config file to obtain behavior that would be chosen automatically if the > config file were absent. > > It should be possible to explicitly specify behavior that matches the > default; just for those of us who don't always trust the defaults not to > change. But it shouldn't be necessary just because a config file exists. > An empty, or comment-only config file should produce the same behavior > as a missing one. A config file with one default behavior explicitly > specified should also produce the same behavior as a missing config > file, or one that explicitly specifies all of the options as matching > the defaults. Please, provide a example of how such configuration file would look. Ok, I might agree to have, for each interface, a hostname.local (A and AAAA, depending on whats available on the interface) and an associated PTR record as the default if we can agree on a easy way to disable this behavior without making the mdns.conf too complex. One example would be to have something such as "override default=yes", in both a global and interface local scope. >> >> The nsswitch.conf should IHMO be :files dns mdns, > >> and the mdns nss module should ship with a default to only allow >> queries to >> .local >> .168.254.in-addr.arpa > > I think you meant .254.168.in-addr.arpa here. Actually .254.169.in-addr.arpa :) > >> .168.192.in-addr.arpa >> .16.172.in-addr.arpa-31.172.in-addr.arpa >> .10.in-addr.arpa > > I put mdns before dns for performance reasons. If you restrict the > queries as defined above, there's no real advantage to doing the dns > query first. Yes, agreed (if restricted). > > I am reluctantly coming to agree that for security reasons we need to > restrict the domains for A record lookups via mDNS; and PTR records in > the in-addr.arpa domain. > I think the reasons are very clear, in a mobile environment you might hook up your laptop to various "untrusted" networks. > But service discovery will often have a non-.local domain; so I think we > need to allow PTR/SVC/TXT lookups in any domain. (Or possibly anything > outside in-addr.arpa. Given the existence of the .local domain, I don't > see any utility in advertising a service in an in-addr.arpa domain. I'm > sure somebody will post an example if I'm just being short-sighted here...) > As you said above SD is not only for mDNS. SD over mDNS should be in the .local domain. A SD browser should go through the normal nss environment to do its searching and not directly consult the mDNS API for all of its queries. Under normal circumstances queries for SD records in existing TLDs should be looked up just as any other DNS record. > > > Not entirely. It is also a syntactic/semantic issue in the config file > design. There's a choice between whether there's an implicit "ignore > this if the necessary protocol isn't available" or some sort of > conditional block to explicitly say 'if condition X, then apply the > following set of options'. The later is potentially more powerful. Yes, I agree. A user might want to advertise a record only if a certain condition is met, however I think we should be careful not to create a too complex syntax. The mdns.conf must be simple enough so that an average user is able to edit it without too much knowledge. We really do not want to turn in into something similar to named.conf, more /etc/hosts on steroids. Fredrik Lindberg From owner-freebsd-net@FreeBSD.ORG Thu Aug 24 21:51:00 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 572EC16A4E2; Thu, 24 Aug 2006 21:51:00 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from sccmmhc92.asp.att.net (sccmmhc92.asp.att.net [204.127.203.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2499843D46; Thu, 24 Aug 2006 21:50:58 +0000 (GMT) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net ([12.207.12.9]) by sccmmhc92.asp.att.net (sccmmhc92) with ESMTP id <20060824215057m92002sviqe>; Thu, 24 Aug 2006 21:50:57 +0000 Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.13.6/8.13.6) with ESMTP id k7OLommh040466; Thu, 24 Aug 2006 16:50:49 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.13.6/8.13.6/Submit) id k7OLoga1040465; Thu, 24 Aug 2006 16:50:42 -0500 (CDT) (envelope-from brooks) Date: Thu, 24 Aug 2006 16:50:41 -0500 From: Brooks Davis To: Pat Lashley Message-ID: <20060824215041.GA40213@lor.one-eyed-alien.net> References: <44EDA9A5.2050108@shapeshifter.se> <44EDBDD0.4050000@shapeshifter.se> <7CC9AC69410B69EBD31122E4@garrett.local> <44EDDB8C.9090504@shapeshifter.se> <0EC404BA0CA363942D250766@garrett.local> <20060824182640.GA37561@lor.one-eyed-alien.net> <20060824193127.GA38855@lor.one-eyed-alien.net> <806B67472BBA47707142E56E@garrett.local> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gKMricLos+KVdGMg" Content-Disposition: inline In-Reply-To: <806B67472BBA47707142E56E@garrett.local> User-Agent: Mutt/1.5.11 Cc: freebsd-net@freebsd.org, Doug Barton , Fredrik Lindberg Subject: Re: Zeroconfig and Multicast DNS 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, 24 Aug 2006 21:51:00 -0000 --gKMricLos+KVdGMg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 24, 2006 at 02:36:58PM -0400, Pat Lashley wrote: > >> We also need to be able to handle the case where they are on physically > >> different links; but the host is acting as a bridge between them to ma= ke > >> one logical link sharing a single LLA subnet. (We don't need to=20 > >explicitly > >> handle the case where the bridging is being handled externally because= =20 > >that > >> should be virtually indistinguishable from a single physical link.) > > > >If there's a bridge (only considering if_bridge here) then the bridge > >interface should have the LLA. Configuring LLAs on the physical > >interfaces would be wrong and isn't worth supporting. >=20 > It's been a long time since I've set up a bridge; so I'm a bit rusty on a= ll=20 > of the details. But from the if_bridge man page, it doesn't look like the= =20 > bridge interface has an IP address of its own. (And I can't see why it=20 > would want one.) With if_bridge there is a single virtual interface which is the single correct place to hang IP addresses should you wish to both bridge L2 traffic and exchange IP packets. This is similar to the way managed switches work. > Also, I was using 'bridge' as a short-hand which would include any sort o= f=20 > proxying or routing that would make two physical segments operate as one= =20 > local link for address negotiation. >=20 > Overall, I don't really expect that to be a big issue; just one of those= =20 > less common setups that we need to ensure does something reasonable by=20 > default. To be honest, I'm not sure that's even worth much effort to make the default reasonable. Documenting that behavior is undefined in such situations and spending effort on the bigger fish seems much more productive, but if someone wants to do it, they certainly shouldn't let my opinion stop them. I just don't think it's the sort of edge case that should block initial integration into the tree. It's possible to do some amazingly bizarre things with your IP configuration, but I don't think we need to make all of them work. :) > >The right way to deal with this is almost certainly to adopt the KAME > >%interface decoration for link local addresses. LLAs are meaningless > >outside the context of an interface. Unless you only have one interface > >with an LLA, you must know which interface you are addressing to know > >where to send the packet. While you can hack around this in some cases > >by trying all of them and hoping there aren't any collisions, I think > >that's the wrong way to go. >=20 > Except in the case where multiple interfaces are on the same segment for= =20 > redundancy. But in general, I suspect that you are right that using a=20 > %interface notation is the way to go. If you actually want redundancy then you don't want multiple IP addresses since you'll lose all your connections on the interface that goes down. What you actually want is etherchannel in which case you end up with one IP address and one one MAC address. > Now, how do we handle the problem in DNS-SD ? The service records just ha= ve=20 > a domain name. The resolver needs to be smart enough to resolve the domain name to the annotated link local address. For the most part this probably isn't worth worrying about. -- Brooks --gKMricLos+KVdGMg Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFE7h8xXY6L6fI4GtQRArMUAKCeUKcFKB0BkeUQPsxn6ItDIF1vswCgr1i+ WVqLOFhhzBznv2gSIIb1LY8= =2TXg -----END PGP SIGNATURE----- --gKMricLos+KVdGMg-- From owner-freebsd-net@FreeBSD.ORG Thu Aug 24 21:52:06 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5E82F16A4E5; Thu, 24 Aug 2006 21:52:06 +0000 (UTC) (envelope-from fli+freebsd-net@shapeshifter.se) Received: from mx1.h3q.net (manticore.shapeshifter.se [212.37.5.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 62C6343D58; Thu, 24 Aug 2006 21:51:58 +0000 (GMT) (envelope-from fli+freebsd-net@shapeshifter.se) Received: from localhost (localhost [127.0.0.1]) by mx1.h3q.net (Postfix) with ESMTP id 86C201A78D; Thu, 24 Aug 2006 23:51:57 +0200 (CEST) Received: from mx1.h3q.net ([127.0.0.1]) by localhost (mx1.h3q.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 35153-03; Thu, 24 Aug 2006 23:51:56 +0200 (CEST) Received: from [192.168.1.100] (217-208-33-252-o926.tbon.telia.com [217.208.33.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.h3q.net (Postfix) with ESMTP id 958181A72A; Thu, 24 Aug 2006 23:51:56 +0200 (CEST) Message-ID: <44EE1F7B.5000500@shapeshifter.se> Date: Thu, 24 Aug 2006 23:51:55 +0200 From: Fredrik Lindberg User-Agent: Thunderbird 1.5.0.4 (X11/20060727) MIME-Version: 1.0 To: Pat Lashley References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at h3q.net Cc: freebsd-net@freebsd.org, Doug Barton Subject: Re: Zeroconfig and Multicast DNS 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, 24 Aug 2006 21:52:06 -0000 Pat Lashley wrote: > > The problem with that is that we want to support the use of both on the > same link. So we'd either need to allow more than one keyword, or have > 'DHCP', 'LLA', 'LLA+DHCP', etc. Neither of those is very attractive. I > think it would be cleaner to have something like: The magic words aren't mutually exclusive, they are dealt with individually. They could be named LLA4, LLA4FALLBACK and will work together with the other options (DHCP, WPA, etc). > > ipv4-link-local-always="bge* fxp1" > ipv4-link-local-fallback="fxp0" I find this scheme way too different from how other interface configuration is done. Fredrik Lindberg From owner-freebsd-net@FreeBSD.ORG Thu Aug 24 21:58:47 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5142416A4DA for ; Thu, 24 Aug 2006 21:58:47 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.176]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3E71F43D70 for ; Thu, 24 Aug 2006 21:58:31 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from mac.com (smtpin07-en2 [10.13.10.152]) by smtpout.mac.com (Xserve/8.12.11/smtpout06/MantshX 4.0) with ESMTP id k7OLwUsd017215; Thu, 24 Aug 2006 14:58:30 -0700 (PDT) Received: from [17.214.14.142] (a17-214-14-142.apple.com [17.214.14.142]) (authenticated bits=0) by mac.com (Xserve/smtpin07/MantshX 4.0) with ESMTP id k7OLwIJN020127; Thu, 24 Aug 2006 14:58:29 -0700 (PDT) In-Reply-To: References: <20060823221835.GA28978@lor.one-eyed-alien.net> <23D2619F6BACE4E728178EE5@garrett.local> <44ED3BD1.3030206@shapeshifter.se> <44EDA9A5.2050108@shapeshifter.se> <44EDBDD0.4050000@shapeshifter.se> <7CC9AC69410B69EBD31122E4@garrett.local> <44EDDB8C.9090504@shapeshifter.se> <0EC404BA0CA363942D250766@garrett.local> <20060824182640.GA37561@lor.one-eyed-alien.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <22D92E8D-DE18-4883-8E77-5567AF63DFE0@mac.com> Content-Transfer-Encoding: 7bit From: Chuck Swiger Date: Thu, 24 Aug 2006 14:58:17 -0700 To: Pat Lashley X-Mailer: Apple Mail (2.752.2) Cc: freebsd-net@freebsd.org Subject: Re: Zeroconfig and Multicast DNS 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, 24 Aug 2006 21:58:47 -0000 On Aug 24, 2006, at 9:20 AM, Pat Lashley wrote: >> Unless we modify the IPv4 routing code to actually know that >> different >> interfaces with LLAs are on different subnets, we will need to insure >> that there is only one interface with an LLA on it at once. The >> modification probably makes sense, but I have no idea what it would >> entail. > > Actually, it is quite possible for multiple interfaces to be on the > same LLA link/subnet; so we can't make any assumptions either way. > We -do- need to be able to handle the case where they are on > different links. That really isn't an 'unless', it's a 'when'. Yes, the common case would be a machine like a laptop which has both an ethernet and an 802.11 wireless connectivity. If the 802.11 basestation is configured as a bridge to the wired LAN, these two interfaces are really on the same link. This implies that any multihomed system must ensure that if it configures more than one interface for LLA's, the addresses it uses are unique. > We also need to be able to handle the case where they are on > physically different links; but the host is acting as a bridge > between them to make one logical link sharing a single LLA subnet. > (We don't need to explicitly handle the case where the bridging is > being handled externally because that should be virtually > indistinguishable from a single physical link.) Yes, it is reasonable for a device which can bridge two different physical networks to share a single LLA subnet, but the LLA should be assigned to the virtual bridged interface, not to the underlying physical interfaces. > I think this all means that for a multi-homed host, we should not > automatically add a route for the 169.254/16 network. Instead, we > should just add specific /32s as discovered; and use ARP when we > need to find a new 169.254.x.y -> MAC translation. MacOS X has the notion of interface priorities; from RFC-3927: Mac OS X ensures that the connected interface with the highest priority is associated with the Link-Local subnet. Packets addressed to a Link-Local address are never sent to the default gateway, if one is present. Link-local addresses are always resolved on the local segment. Mac OS X implements media sense where the hardware and driver support it. When the network media indicates that it has been connected, the autoconfiguration process begins again, and attempts to re-use the previously assigned Link-Local address. When the network media indicates that it has been disconnected, the system waits four seconds before de-configuring the Link-Local address and subnet. If the connection is restored before that time, the autoconfiguration process begins again. If the connection is not restored before that time, the system chooses another interface to autoconfigure. > There still remains the possibility of multiple distinct hosts > having the same LLA IP address on separate local links; each > attached to a separate interface. In practice that situation should > be sufficiently rare that we can afford to ignore it until someone > comes up with some clever way to handle it. (Or we all move to IPv6 > and it becomes moot.) See section 4 of RFC-3927. -- -Chuck From owner-freebsd-net@FreeBSD.ORG Thu Aug 24 22:03:32 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0795316A4DA; Thu, 24 Aug 2006 22:03:32 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from sccmmhc92.asp.att.net (sccmmhc92.asp.att.net [204.127.203.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1125A43D5E; Thu, 24 Aug 2006 22:03:30 +0000 (GMT) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net ([12.207.12.9]) by sccmmhc92.asp.att.net (sccmmhc92) with ESMTP id <20060824220330m92002rs3ke>; Thu, 24 Aug 2006 22:03:30 +0000 Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.13.6/8.13.6) with ESMTP id k7OM3OnB040611; Thu, 24 Aug 2006 17:03:24 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.13.6/8.13.6/Submit) id k7OM3KWH040610; Thu, 24 Aug 2006 17:03:20 -0500 (CDT) (envelope-from brooks) Date: Thu, 24 Aug 2006 17:03:14 -0500 From: Brooks Davis To: Fredrik Lindberg Message-ID: <20060824220314.GB40213@lor.one-eyed-alien.net> References: <44EE1F7B.5000500@shapeshifter.se> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1LKvkjL3sHcu1TtY" Content-Disposition: inline In-Reply-To: <44EE1F7B.5000500@shapeshifter.se> User-Agent: Mutt/1.5.11 Cc: freebsd-net@freebsd.org, Pat Lashley , Doug Barton Subject: Re: Zeroconfig and Multicast DNS 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, 24 Aug 2006 22:03:32 -0000 --1LKvkjL3sHcu1TtY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 24, 2006 at 11:51:55PM +0200, Fredrik Lindberg wrote: > Pat Lashley wrote: > > > >The problem with that is that we want to support the use of both on the= =20 > >same link. So we'd either need to allow more than one keyword, or have= =20 > >'DHCP', 'LLA', 'LLA+DHCP', etc. Neither of those is very attractive. I= =20 > >think it would be cleaner to have something like: >=20 > The magic words aren't mutually exclusive, they are dealt with > individually. They could be named LLA4, LLA4FALLBACK and will > work together with the other options (DHCP, WPA, etc). It just occured to me that the daemon could handle this without any interaction with dhclient or the static interface configuration. In the mode where you only want an LLA if there isn't another address it's a simple matter of watching the routing socket for messages and a) removing the LLA if an IPv4 address other than 0.0.0.0 is configured on the interface and b) (re)starting the process of obtaining an LLA when all other addresses have been removed. The daemon should be listening to the routing socket anyway because it should only run when the interface has link which requires it to exit when the link goes down similar to dhclient. I really need to go look at the code and see what you're doing now. :) > > ipv4-link-local-always=3D"bge* fxp1" > > ipv4-link-local-fallback=3D"fxp0" >=20 > I find this scheme way too different from how other interface > configuration is done. Me too. I like the tags (obviously since I invented most of them :). I'm attempting to get rid of as many lists of interfaces as possible. -- Brooks --1LKvkjL3sHcu1TtY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFE7iIiXY6L6fI4GtQRAkrUAKDXtIvlUeQDQ0XpyOXHj9BxvjSxZgCgnthv ACtjAFzGdYRIBrRZb445+Ik= =q0EA -----END PGP SIGNATURE----- --1LKvkjL3sHcu1TtY-- From owner-freebsd-net@FreeBSD.ORG Thu Aug 24 22:05:46 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 562FA16A4DA for ; Thu, 24 Aug 2006 22:05:46 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id DB06C43D64 for ; Thu, 24 Aug 2006 22:05:37 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from mac.com (smtpin03-en2 [10.13.10.148]) by smtpout.mac.com (Xserve/8.12.11/smtpout07/MantshX 4.0) with ESMTP id k7OM5WBx016640; Thu, 24 Aug 2006 15:05:32 -0700 (PDT) Received: from [17.214.14.142] (a17-214-14-142.apple.com [17.214.14.142]) (authenticated bits=0) by mac.com (Xserve/smtpin03/MantshX 4.0) with ESMTP id k7OM5Pc0016085; Thu, 24 Aug 2006 15:05:30 -0700 (PDT) In-Reply-To: <44EE1E48.6000006@shapeshifter.se> References: <44EE1E48.6000006@shapeshifter.se> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Chuck Swiger Date: Thu, 24 Aug 2006 15:05:24 -0700 To: Fredrik Lindberg X-Mailer: Apple Mail (2.752.2) X-Brightmail-Tracker: AAAAAQAAA+k= X-Language-Identified: TRUE Cc: freebsd-net@freebsd.org Subject: Re: Zeroconfig and Multicast DNS 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, 24 Aug 2006 22:05:46 -0000 On Aug 24, 2006, at 2:46 PM, Fredrik Lindberg wrote: >>> The nsswitch.conf should IHMO be :files dns mdns, >>> and the mdns nss module should ship with a default to only allow >>> queries to >>> .local >>> .168.254.in-addr.arpa >> I think you meant .254.168.in-addr.arpa here. > > Actually .254.169.in-addr.arpa :) Queries to 254.169.in-addr.arpa MUST return NXDOMAIN (or RCODE 3, to choose a non-BIND specific term). See RFC-3927, section 1.4: To preclude use of IPv4 Link-Local addresses in off-link communication, the following cautionary measures are advised: a. IPv4 Link-Local addresses MUST NOT be configured in the DNS. Mapping from IPv4 addresses to host names is conventionally done by issuing DNS queries for names of the form, "x.x.x.x.in-addr.arpa." When used for link-local addresses, which have significance only on the local link, it is inappropriate to send such DNS queries beyond the local link. DNS clients MUST NOT send DNS queries for any name that falls within the "254.169.in-addr.arpa." domain. DNS recursive name servers receiving queries from non-compliant clients for names within the "254.169.in-addr.arpa." domain MUST by default return RCODE 3, authoritatively asserting that no such name exists in the Domain Name System. b. Names that are globally resolvable to routable addresses should be used within applications whenever they are available. Names that are resolvable only on the local link (such as through use of protocols such as Link Local Multicast Name Resolution [LLMNR]) MUST NOT be used in off-link communication. IPv4 addresses and names that can only be resolved on the local link SHOULD NOT be forwarded beyond the local link. IPv4 Link-Local addresses SHOULD only be sent when a Link-Local address is used as the source and/or destination address. This strong advice should hinder limited scope addresses and names from leaving the context in which they apply. -- -Chuck From owner-freebsd-net@FreeBSD.ORG Thu Aug 24 22:06:40 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4B0E116A4E0; Thu, 24 Aug 2006 22:06:40 +0000 (UTC) (envelope-from fli+freebsd-net@shapeshifter.se) Received: from mx1.h3q.net (manticore.shapeshifter.se [212.37.5.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 115A243D53; Thu, 24 Aug 2006 22:06:35 +0000 (GMT) (envelope-from fli+freebsd-net@shapeshifter.se) Received: from localhost (localhost [127.0.0.1]) by mx1.h3q.net (Postfix) with ESMTP id 0C1981A78E; Fri, 25 Aug 2006 00:06:34 +0200 (CEST) Received: from mx1.h3q.net ([127.0.0.1]) by localhost (mx1.h3q.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 35153-08; Fri, 25 Aug 2006 00:06:33 +0200 (CEST) Received: from [192.168.1.100] (217-208-33-252-o926.tbon.telia.com [217.208.33.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.h3q.net (Postfix) with ESMTP id 31A4F1A72A; Fri, 25 Aug 2006 00:06:33 +0200 (CEST) Message-ID: <44EE22E7.6000700@shapeshifter.se> Date: Fri, 25 Aug 2006 00:06:31 +0200 From: Fredrik Lindberg User-Agent: Thunderbird 1.5.0.4 (X11/20060727) MIME-Version: 1.0 To: Brooks Davis References: <44EE1F7B.5000500@shapeshifter.se> <20060824220314.GB40213@lor.one-eyed-alien.net> In-Reply-To: <20060824220314.GB40213@lor.one-eyed-alien.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at h3q.net Cc: freebsd-net@freebsd.org, Pat Lashley , Doug Barton Subject: Re: Zeroconfig and Multicast DNS 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, 24 Aug 2006 22:06:40 -0000 Brooks Davis wrote: > > It just occured to me that the daemon could handle this without any > interaction with dhclient or the static interface configuration. In the > mode where you only want an LLA if there isn't another address it's a > simple matter of watching the routing socket for messages and a) > removing the LLA if an IPv4 address other than 0.0.0.0 is configured on > the interface and b) (re)starting the process of obtaining an LLA when > all other addresses have been removed. The daemon should be listening > to the routing socket anyway because it should only run when the > interface has link which requires it to exit when the link goes down > similar to dhclient. I really need to go look at the code and see what > you're doing now. :) Well, I'm doing just that...except it's not the routing socket but the netdev filter of the kqueue system. Could be change to the routing socket. Fredrik Lindberg From owner-freebsd-net@FreeBSD.ORG Thu Aug 24 22:10:52 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1A0C616A4DF for ; Thu, 24 Aug 2006 22:10:52 +0000 (UTC) (envelope-from fli+freebsd-net@shapeshifter.se) Received: from mx1.h3q.net (manticore.shapeshifter.se [212.37.5.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9600343D46 for ; Thu, 24 Aug 2006 22:10:51 +0000 (GMT) (envelope-from fli+freebsd-net@shapeshifter.se) Received: from localhost (localhost [127.0.0.1]) by mx1.h3q.net (Postfix) with ESMTP id B525F1A7B4; Fri, 25 Aug 2006 00:10:50 +0200 (CEST) Received: from mx1.h3q.net ([127.0.0.1]) by localhost (mx1.h3q.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 35153-10; Fri, 25 Aug 2006 00:10:49 +0200 (CEST) Received: from [192.168.1.100] (217-208-33-252-o926.tbon.telia.com [217.208.33.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.h3q.net (Postfix) with ESMTP id 18C641A7A9; Fri, 25 Aug 2006 00:10:49 +0200 (CEST) Message-ID: <44EE23E7.2010800@shapeshifter.se> Date: Fri, 25 Aug 2006 00:10:47 +0200 From: Fredrik Lindberg User-Agent: Thunderbird 1.5.0.4 (X11/20060727) MIME-Version: 1.0 To: Chuck Swiger References: <44EE1E48.6000006@shapeshifter.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at h3q.net Cc: freebsd-net@freebsd.org Subject: Re: Zeroconfig and Multicast DNS 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, 24 Aug 2006 22:10:52 -0000 Chuck Swiger wrote: > On Aug 24, 2006, at 2:46 PM, Fredrik Lindberg wrote: >>>> The nsswitch.conf should IHMO be :files dns mdns, >>>> and the mdns nss module should ship with a default to only allow >>>> queries to >>>> .local >>>> .168.254.in-addr.arpa >>> I think you meant .254.168.in-addr.arpa here. >> >> Actually .254.169.in-addr.arpa :) > > Queries to 254.169.in-addr.arpa MUST return NXDOMAIN (or RCODE 3, to > choose a non-BIND specific term). We're talking about mDNS here, not DNS. I would argue that because mDNS is link-local it makes perfect sense to be able to resolve 254.169.in-addr.arpa using mDNS. Fredrik Lindberg From owner-freebsd-net@FreeBSD.ORG Thu Aug 24 22:21:51 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E833C16A4DE for ; Thu, 24 Aug 2006 22:21:51 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.183]) by mx1.FreeBSD.org (Postfix) with ESMTP id E90B943D60 for ; Thu, 24 Aug 2006 22:21:47 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from mac.com (smtpin04-en2 [10.13.10.149]) by smtpout.mac.com (Xserve/8.12.11/smtpout13/MantshX 4.0) with ESMTP id k7OMLlFE001422; Thu, 24 Aug 2006 15:21:47 -0700 (PDT) Received: from [17.214.14.142] (a17-214-14-142.apple.com [17.214.14.142]) (authenticated bits=0) by mac.com (Xserve/smtpin04/MantshX 4.0) with ESMTP id k7OMLgTG021014; Thu, 24 Aug 2006 15:21:44 -0700 (PDT) In-Reply-To: <44EE23E7.2010800@shapeshifter.se> References: <44EE1E48.6000006@shapeshifter.se> <44EE23E7.2010800@shapeshifter.se> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Chuck Swiger Date: Thu, 24 Aug 2006 15:21:41 -0700 To: Fredrik Lindberg X-Mailer: Apple Mail (2.752.2) X-Brightmail-Tracker: AAAAAQAAA+k= X-Language-Identified: TRUE Cc: freebsd-net@freebsd.org Subject: Re: Zeroconfig and Multicast DNS 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, 24 Aug 2006 22:21:52 -0000 On Aug 24, 2006, at 3:10 PM, Fredrik Lindberg wrote: >> Queries to 254.169.in-addr.arpa MUST return NXDOMAIN (or RCODE 3, >> to choose a non-BIND specific term). > > We're talking about mDNS here, not DNS. I would argue that because > mDNS is link-local it makes perfect sense to be able to resolve > 254.169.in-addr.arpa using mDNS. True, agreed-- that's in part (b) of what I quoted. The specific part is: "Names that are resolvable only on the local link (such as through use of protocols such as Link Local Multicast Name Resolution [LLMNR]) MUST NOT be used in off-link communication." What this means is that the hostname-to-address mapping for 254.169.in-addr.arpa addresses must be unique per interface. If you have two interfaces which are connected to different LLA subnets, 169.254.1.1 might map to hostnameA on one, and that same IP might be hostnameB on the other. -- -Chuck From owner-freebsd-net@FreeBSD.ORG Thu Aug 24 22:38:15 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1ED6816A4DA; Thu, 24 Aug 2006 22:38:15 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from sccmmhc92.asp.att.net (sccmmhc92.asp.att.net [204.127.203.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8037643D46; Thu, 24 Aug 2006 22:38:14 +0000 (GMT) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net ([12.207.12.9]) by sccmmhc92.asp.att.net (sccmmhc92) with ESMTP id <20060824223813m92002sad6e>; Thu, 24 Aug 2006 22:38:13 +0000 Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.13.6/8.13.6) with ESMTP id k7OMc6KH040916; Thu, 24 Aug 2006 17:38:07 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.13.6/8.13.6/Submit) id k7OMbvfm040915; Thu, 24 Aug 2006 17:37:57 -0500 (CDT) (envelope-from brooks) Date: Thu, 24 Aug 2006 17:37:57 -0500 From: Brooks Davis To: Fredrik Lindberg Message-ID: <20060824223756.GC40213@lor.one-eyed-alien.net> References: <44EE1F7B.5000500@shapeshifter.se> <20060824220314.GB40213@lor.one-eyed-alien.net> <44EE22E7.6000700@shapeshifter.se> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tqI+Z3u+9OQ7kwn0" Content-Disposition: inline In-Reply-To: <44EE22E7.6000700@shapeshifter.se> User-Agent: Mutt/1.5.11 Cc: freebsd-net@freebsd.org, Pat Lashley , Doug Barton Subject: Re: Zeroconfig and Multicast DNS 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, 24 Aug 2006 22:38:15 -0000 --tqI+Z3u+9OQ7kwn0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 25, 2006 at 12:06:31AM +0200, Fredrik Lindberg wrote: > Brooks Davis wrote: > > > >It just occured to me that the daemon could handle this without any > >interaction with dhclient or the static interface configuration. In the > >mode where you only want an LLA if there isn't another address it's a > >simple matter of watching the routing socket for messages and a) > >removing the LLA if an IPv4 address other than 0.0.0.0 is configured on > >the interface and b) (re)starting the process of obtaining an LLA when > >all other addresses have been removed. The daemon should be listening > >to the routing socket anyway because it should only run when the > >interface has link which requires it to exit when the link goes down > >similar to dhclient. I really need to go look at the code and see what > >you're doing now. :) >=20 > Well, I'm doing just that...except it's not the routing socket but the > netdev filter of the kqueue system. Could be change to the routing > socket. It looks like you'd need to switch to the routing socket to be able to make decisions based on address changes, but the basic flow should be the same. -- Brooks --tqI+Z3u+9OQ7kwn0 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFE7ipEXY6L6fI4GtQRAvGhAJ4z8edlI4w3Y0DfjjfbzhgbPBPdJACgifJC k481niMwUpd3dGxsNJ7Wi8k= =Xx9t -----END PGP SIGNATURE----- --tqI+Z3u+9OQ7kwn0-- From owner-freebsd-net@FreeBSD.ORG Thu Aug 24 22:45:20 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5A66316A4DE for ; Thu, 24 Aug 2006 22:45:20 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from sccmmhc91.asp.att.net (sccmmhc91.asp.att.net [204.127.203.211]) by mx1.FreeBSD.org (Postfix) with ESMTP id ADC1943D46 for ; Thu, 24 Aug 2006 22:45:14 +0000 (GMT) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net ([12.207.12.9]) by sccmmhc91.asp.att.net (sccmmhc91) with ESMTP id <20060824224513m9100862f6e>; Thu, 24 Aug 2006 22:45:13 +0000 Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.13.6/8.13.6) with ESMTP id k7OMjAni041010; Thu, 24 Aug 2006 17:45:11 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.13.6/8.13.6/Submit) id k7OMjAVp041009; Thu, 24 Aug 2006 17:45:10 -0500 (CDT) (envelope-from brooks) Date: Thu, 24 Aug 2006 17:45:09 -0500 From: Brooks Davis To: Chuck Swiger Message-ID: <20060824224509.GD40213@lor.one-eyed-alien.net> References: <44EE1E48.6000006@shapeshifter.se> <44EE23E7.2010800@shapeshifter.se> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NtwzykIc2mflq5ck" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11 Cc: freebsd-net@freebsd.org, Fredrik Lindberg Subject: Re: Zeroconfig and Multicast DNS 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, 24 Aug 2006 22:45:20 -0000 --NtwzykIc2mflq5ck Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 24, 2006 at 03:21:41PM -0700, Chuck Swiger wrote: > On Aug 24, 2006, at 3:10 PM, Fredrik Lindberg wrote: > >>Queries to 254.169.in-addr.arpa MUST return NXDOMAIN (or RCODE 3, =20 > >>to choose a non-BIND specific term). > > > >We're talking about mDNS here, not DNS. I would argue that because > >mDNS is link-local it makes perfect sense to be able to resolve > >254.169.in-addr.arpa using mDNS. >=20 > True, agreed-- that's in part (b) of what I quoted. The specific =20 > part is: >=20 > "Names that are resolvable only on the local link (such as through =20 > use of > protocols such as Link Local Multicast Name Resolution [LLMNR]) MUST NOT > be used in off-link communication." >=20 > What this means is that the hostname-to-address mapping for =20 > 254.169.in-addr.arpa addresses must be unique per interface. If you =20 > have two interfaces which are connected to different LLA subnets, =20 > 169.254.1.1 might map to hostnameA on one, and that same IP might be =20 > hostnameB on the other. Hmm, that seems to argue for some further namespace mangling so forward lookups make sense. From that perspective the namespace really should be xxx..local internally and xxx.local on the wire. Actually doing that would probably cause all sorts of problems though. :( -- Brooks --NtwzykIc2mflq5ck Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFE7iv1XY6L6fI4GtQRAjMVAJ4+KuzBkl9Yz3cl6utDAXzcFShCUgCg4UAg a1zXs96+/xoUn7OiZhOlDbE= =b3/E -----END PGP SIGNATURE----- --NtwzykIc2mflq5ck-- From owner-freebsd-net@FreeBSD.ORG Fri Aug 25 00:29:57 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1B78516A4DE for ; Fri, 25 Aug 2006 00:29:57 +0000 (UTC) (envelope-from bmw@borderware.com) Received: from mail.borderware.com (mail.borderware.com [207.236.65.231]) by mx1.FreeBSD.org (Postfix) with ESMTP id BF80943D69 for ; Fri, 25 Aug 2006 00:29:55 +0000 (GMT) (envelope-from bmw@borderware.com) Message-ID: <44EE4481.3000201@borderware.com> Date: Thu, 24 Aug 2006 20:29:53 -0400 From: Bruce Walker User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Fwd: New Bonjour Internet Drafts posted] 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, 25 Aug 2006 00:29:57 -0000 Re the ZeroConf/Bonjour/IPv4LL chat: this just in ... -------- Original Message -------- Subject: New Bonjour Internet Drafts posted Date: Thu, 24 Aug 2006 17:20:23 -0700 From: Marc Krochmal To: bonjour-dev@lists.apple.com Hello, Today we submitted the latest versions of the Bonjour draft specs to the IETF. They're also available from here... The majority of the changes were in the mDNS and DNS-SD drafts. The following new sections were added to the mDNS draft. 6.7 Direct Unicast Queries to port 5353 16. Considerations for Multiple Responders on the Same Machine 16.1 Receiving Unicast Responses 16.2 Multi-Packet Known-Answer lists 16.3 Efficiency 16.4 Recommendation 28. Deployment History Most of the technical changes were related to probing and probe tie- breaking but these changes shouldn't affect backward compatibility with any existing products. The following new sections were added to the DNS-SD draft. 16. User Interface Considerations 16.1 Service Advertising User-Interface Considerations 16.2 Client Browsing User-Interface Considerations 21. Deployment History The mDNS and DNS-SD drafts are very mature now and are close to being ready to publish, most likely as Informational RFCs. If you haven't read them in a while, now would be a good time to skim them over and provide any remaining feedback. Thanks. -Marc _______________________________________________ Do not post admin requests to the list. They will be ignored. Bonjour-dev mailing list (Bonjour-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/bonjour-dev/bmw%40borderware.com This email sent to bmw@borderware.com From owner-freebsd-net@FreeBSD.ORG Fri Aug 25 01:35:43 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6AE7B16A4DD; Fri, 25 Aug 2006 01:35:43 +0000 (UTC) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by mx1.FreeBSD.org (Postfix) with ESMTP id 00FD743D46; Fri, 25 Aug 2006 01:35:42 +0000 (GMT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from impact.jinmei.org (unknown [2001:200:1b1:1010:3d5a:cc2c:134c:d985]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 5D20015228; Fri, 25 Aug 2006 10:35:41 +0900 (JST) Date: Fri, 25 Aug 2006 10:35:03 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Brooks Davis In-Reply-To: <20060824184228.GC37561@lor.one-eyed-alien.net> References: <3E654CC0217F90E20FCD806E@garrett.local> <44EC90B7.6090908@shapeshifter.se> <44ECB0F2.9040300@FreeBSD.org> <44ECBB61.9020808@shapeshifter.se> <5D7785ADC030FEBFB9A5E69D@garrett.local> <44ED8266.1060303@shapeshifter.se> <7C6CDF1CB0BC58A6ADE1FCA8@garrett.local> <44EDCEC2.7060109@shapeshifter.se> <93381966E13B960D4ACFF05C@garrett.local> <44EDF116.9050106@shapeshifter.se> <20060824184228.GC37561@lor.one-eyed-alien.net> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: freebsd-net@freebsd.org, Pat Lashley , Doug Barton , Fredrik Lindberg Subject: Re: Zeroconfig and Multicast DNS 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, 25 Aug 2006 01:35:43 -0000 >>>>> On Thu, 24 Aug 2006 13:42:29 -0500, >>>>> Brooks Davis said: >> Um...I'm not sure if this is even possible. Let's forget mDNS and >> go back to basic IP. >> Say a multi-homed host has two interfaces both configured with an >> address in the rage 169.254/16, say 169.254.1.1 and 169.254.2.1 and >> it wants to initiate a connection to 169.254.3.1, how on earth should >> it be able to tell on which side 3.1 is located? There might even be >> one 3.1 on both side that could be completely different hosts. > You probably would need an extension similiar to the one for IPv6 LLAs. > i.e. the %bge0 in fe80::2e0:81ff:fe31:9f00%bge0. (I've not followed the discussion closely, so my apologize in advance if this message reacts to an off-topic.) Note that the '%bge0' notation works well thanks to the sin6_scope_id field of the sockaddr_in6{} structure. Since sockaddr_in{} doesn't have such an additional member to solve the ambiguity, the extension to the IPv4 addresses would not be that trivial. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-freebsd-net@FreeBSD.ORG Fri Aug 25 03:39:34 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CD97616A4E0; Fri, 25 Aug 2006 03:39:34 +0000 (UTC) (envelope-from patl+freebsd@volant.org) Received: from smtp.volant.org (gate.volant.org [207.111.218.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 36DA743D46; Fri, 25 Aug 2006 03:39:34 +0000 (GMT) (envelope-from patl+freebsd@volant.org) Received: from ip70-171-56-90.ga.at.cox.net ([70.171.56.90] helo=[192.168.1.121]) by smtp.volant.org with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34 (FreeBSD)) id 1GGSaZ-0003Np-PV; Thu, 24 Aug 2006 20:42:53 -0700 Date: Thu, 24 Aug 2006 20:38:20 -0400 From: Pat Lashley To: Brooks Davis Message-ID: <09056343DD7153FCD23C29A0@garrett.local> X-Mailer: Mulberry/4.0.0 (Mac OS X) MIME-Version: 1.0 X-Scan-Signature: 252dccae112cc0732fabc0b517e5aa93cccc8ba5 X-Spam-User: nobody X-Spam-Score: -4.3 (----) X-Spam-Score-Int: -42 X-Spam-Report: This mail has matched the spam-filter tests listed below. See http://spamassassin.org/tag/ for details about the specific tests reported. In general, the higher the number of total points, the more likely that it actually is spam. (The 'required' number of points listed below is the arbitrary number above which the message is normally considered spam.) Content analysis details: (-4.3 points total, 5.0 required) 0.1 HTML_MESSAGE BODY: HTML included in message 0.1 HTML_FONTCOLOR_RED BODY: HTML font color is red -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.4 DATE_IN_PAST_03_06 Date: is 3 to 6 hours before Received: date Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, Doug Barton , Fredrik Lindberg Subject: Re: Zeroconfig and Multicast DNS 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, 25 Aug 2006 03:39:34 -0000 > > Except in the case where multiple interfaces are on the same segment for > > redundancy. But in general, I suspect that you are right that using a > > %interface notation is the way to go. > > If you actually want redundancy then you don't want multiple IP > addresses since you'll lose all your connections on the interface that > goes down. What you actually want is etherchannel in which case you end > up with one IP address and one one MAC address. Yeah, but a lot of people are going to to just figure that since their system came with two Ethernet ports, they should just plug them both in. Possibly to two different switches; but often not even that. > > Now, how do we handle the problem in DNS-SD ? The service records just have > > a domain name. > > The resolver needs to be smart enough to resolve the domain name to the > annotated link local address. For the most part this probably isn't > worth worrying about. I'm not sure that we necessarily have enough information to do that. I think we should in the simple cases using only mDNS. Bbut when you start mixing in the possibility of unicast DNS for service advertisement. And the indirect PTR schemes that are suggested for handling things like making services with spaces in their names available to Windows, which doesn't accept spaces. Then the possibility of different machines using the same .local FQDN, each visible on a different interface. And some mDNS server(s) configured to advertise services on behalf of non-DNS-SD-aware hosts. I'm not sure the we're guaranteed enough info. I'd be happy to find out that I'm wrong here; but I just don't have the time to work through all of the potential scenaria. -Pat From owner-freebsd-net@FreeBSD.ORG Fri Aug 25 04:30:48 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1B6E516A4DA for ; Fri, 25 Aug 2006 04:30:48 +0000 (UTC) (envelope-from patl+freebsd@volant.org) Received: from smtp.volant.org (gate.volant.org [207.111.218.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 80FD443D45 for ; Fri, 25 Aug 2006 04:30:47 +0000 (GMT) (envelope-from patl+freebsd@volant.org) Received: from ip70-171-56-90.ga.at.cox.net ([70.171.56.90] helo=[192.168.1.121]) by smtp.volant.org with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34 (FreeBSD)) id 1GGTOG-0003pc-E3; Thu, 24 Aug 2006 21:34:03 -0700 Date: Thu, 24 Aug 2006 21:29:43 -0400 From: Pat Lashley To: Chuck Swiger Message-ID: <961EF4A5A611779A598DE704@garrett.local> In-Reply-To: <22D92E8D-DE18-4883-8E77-5567AF63DFE0@mac.com> References: <20060823221835.GA28978@lor.one-eyed-alien.net> <23D2619F6BACE4E728178EE5@garrett.local> <44ED3BD1.3030206@shapeshifter.se> <44EDA9A5.2050108@shapeshifter.se> <44EDBDD0.4050000@shapeshifter.se> <7CC9AC69410B69EBD31122E4@garrett.local> <44EDDB8C.9090504@shapeshifter.se> <0EC404BA0CA363942D250766@garrett.local> <20060824182640.GA37561@lor.one-eyed-alien.net> <22D92E8D-DE18-4883-8E77-5567AF63DFE0@mac.com> X-Mailer: Mulberry/4.0.0 (Mac OS X) MIME-Version: 1.0 X-Scan-Signature: c3a39018b38c417fb5ac3615a033779d7854f3fc X-Spam-User: nobody X-Spam-Score: -4.3 (----) X-Spam-Score-Int: -42 X-Spam-Report: This mail has matched the spam-filter tests listed below. See http://spamassassin.org/tag/ for details about the specific tests reported. In general, the higher the number of total points, the more likely that it actually is spam. (The 'required' number of points listed below is the arbitrary number above which the message is normally considered spam.) Content analysis details: (-4.3 points total, 5.0 required) 0.1 HTML_MESSAGE BODY: HTML included in message 0.1 HTML_FONTCOLOR_RED BODY: HTML font color is red -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.4 DATE_IN_PAST_03_06 Date: is 3 to 6 hours before Received: date Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: Zeroconfig and Multicast DNS 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, 25 Aug 2006 04:30:48 -0000 > > I think this all means that for a multi-homed host, we should not > > automatically add a route for the 169.254/16 network. Instead, we > > should just add specific /32s as discovered; and use ARP when we > > need to find a new 169.254.x.y -> MAC translation. > > MacOS X has the notion of interface priorities; from RFC-3927: > > Mac OS X ensures that the connected interface with the highest > priority is associated with the Link-Local subnet. Packets addressed > to a Link-Local address are never sent to the default gateway, if one > is present. Link-local addresses are always resolved on the local > segment. > > Mac OS X implements media sense where the hardware and driver support > it. When the network media indicates that it has been connected, the > autoconfiguration process begins again, and attempts to re-use the > previously assigned Link-Local address. When the network media > indicates that it has been disconnected, the system waits four > seconds before de-configuring the Link-Local address and subnet. If > the connection is restored before that time, the autoconfiguration > process begins again. If the connection is not restored before that > time, the system chooses another interface to autoconfigure. But OS X also only supports Zeroconf on one interface at a time. We Can Do Better. > > There still remains the possibility of multiple distinct hosts > > having the same LLA IP address on separate local links; each > > attached to a separate interface. In practice that situation should > > be sufficiently rare that we can afford to ignore it until someone > > comes up with some clever way to handle it. (Or we all move to IPv6 > > and it becomes moot.) > > See section 4 of RFC-3927. No, that covers merging two previously disjoint networks; I don't think that it is intended to handle the case of a multi-homed host that is connected to both of them while keeping them separate. -Pat From owner-freebsd-net@FreeBSD.ORG Fri Aug 25 04:32:56 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4C6D616A4DD; Fri, 25 Aug 2006 04:32:56 +0000 (UTC) (envelope-from patl@phoenix.volant.org) Received: from orwell.phoenix.volant.org (64-144-229-193.client.dsl.net [64.144.229.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 763CD43D62; Fri, 25 Aug 2006 04:32:46 +0000 (GMT) (envelope-from patl@phoenix.volant.org) Received: from [172.24.16.2] by orwell.phoenix.volant.org with esmtp (Exim 4.62 (FreeBSD)) (envelope-from ) id 1GGTN3-0001Pk-Ot; Thu, 24 Aug 2006 21:32:42 -0700 Date: Fri, 25 Aug 2006 00:32:25 -0400 From: PM Lashley To: Fredrik Lindberg Message-ID: <72BA6AF827AADB0CFEB845DA@2EEC3F7CCB6B8A97580F632A> X-Mailer: Mulberry/4.0.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, Doug Barton Subject: Re: Zeroconfig and Multicast DNS 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, 25 Aug 2006 04:32:56 -0000 > >> The nsswitch.conf should IHMO be :files dns mdns, > > > >> and the mdns nss module should ship with a default to only allow > >> queries to > >> .local > >> .168.254.in-addr.arpa > > > > I think you meant .254.168.in-addr.arpa here. > > Actually .254.169.in-addr.arpa :) Err, yes. I knew that... :-) > >> .168.192.in-addr.arpa > >> .16.172.in-addr.arpa-31.172.in-addr.arpa > >> .10.in-addr.arpa > > > > I put mdns before dns for performance reasons. If you restrict the > > queries as defined above, there's no real advantage to doing the dns > > query first. > > Yes, agreed (if restricted). > > > > > I am reluctantly coming to agree that for security reasons we need to > > restrict the domains for A record lookups via mDNS; and PTR records in > > the in-addr.arpa domain. > > > > I think the reasons are very clear, in a mobile environment you might > hook up your laptop to various "untrusted" networks. Just because they're clear doesn't mean that I'm happy with them. But then I'm not happy with the need to lock my car or my front door either; but I recognize the need to do so. > > But service discovery will often have a non-.local domain; so I think we > > need to allow PTR/SVC/TXT lookups in any domain. (Or possibly anything > > outside in-addr.arpa. Given the existence of the .local domain, I don't > > see any utility in advertising a service in an in-addr.arpa domain. I'm > > sure somebody will post an example if I'm just being short-sighted here...) > > As you said above SD is not only for mDNS. SD over mDNS should be in the > .local domain. A SD browser should go through the normal nss environment > to do its searching and not directly consult the mDNS API for all of its > queries. Under normal circumstances queries for SD records in existing > TLDs should be looked up just as any other DNS record. No, I don't think that there's any good reason to restrict mDNS service discovery to .local; when you're using some other domain on the LAN, you still want to easily do the dynamic service advertisement, even if the A records are being handled by a traditional unicast DNS server and static IP allocation. > > Not entirely. It is also a syntactic/semantic issue in the config file > > design. There's a choice between whether there's an implicit "ignore > > this if the necessary protocol isn't available" or some sort of > > conditional block to explicitly say 'if condition X, then apply the > > following set of options'. The later is potentially more powerful. > > Yes, I agree. A user might want to advertise a record only if a > certain condition is met, however I think we should be careful > not to create a too complex syntax. > The mdns.conf must be simple enough so that an average user is > able to edit it without too much knowledge. > We really do not want to turn in into something similar to named.conf, > more /etc/hosts on steroids. We can define the basic conditional block and some simple conditional tests for things like 'is interface X currently supporting IPv4?' or 'is interface X a point-to-point link?'; and possibly a 'for each '. And then add condition tests as necessary/desirable later. -Pat From owner-freebsd-net@FreeBSD.ORG Fri Aug 25 06:21:20 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 03C0616A4DE; Fri, 25 Aug 2006 06:21:20 +0000 (UTC) (envelope-from fli+freebsd-net@shapeshifter.se) Received: from mx1.h3q.net (manticore.shapeshifter.se [212.37.5.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 795AB43D4C; Fri, 25 Aug 2006 06:21:19 +0000 (GMT) (envelope-from fli+freebsd-net@shapeshifter.se) Received: from localhost (localhost [127.0.0.1]) by mx1.h3q.net (Postfix) with ESMTP id 21AEA1A78D; Fri, 25 Aug 2006 08:21:17 +0200 (CEST) Received: from mx1.h3q.net ([127.0.0.1]) by localhost (mx1.h3q.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42880-06; Fri, 25 Aug 2006 08:21:16 +0200 (CEST) Received: from [192.168.1.100] (217-208-33-252-o926.tbon.telia.com [217.208.33.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.h3q.net (Postfix) with ESMTP id F24941A751; Fri, 25 Aug 2006 08:21:15 +0200 (CEST) Message-ID: <44EE96D8.3040806@shapeshifter.se> Date: Fri, 25 Aug 2006 08:21:12 +0200 From: Fredrik Lindberg User-Agent: Thunderbird 1.5.0.4 (X11/20060727) MIME-Version: 1.0 To: Brooks Davis References: <44EE1F7B.5000500@shapeshifter.se> <20060824220314.GB40213@lor.one-eyed-alien.net> <44EE22E7.6000700@shapeshifter.se> <20060824223756.GC40213@lor.one-eyed-alien.net> In-Reply-To: <20060824223756.GC40213@lor.one-eyed-alien.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at h3q.net Cc: freebsd-net@freebsd.org, Pat Lashley , Doug Barton Subject: Re: Zeroconfig and Multicast DNS 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, 25 Aug 2006 06:21:20 -0000 Brooks Davis wrote: > On Fri, Aug 25, 2006 at 12:06:31AM +0200, Fredrik Lindberg wrote: >> Brooks Davis wrote: >>> It just occured to me that the daemon could handle this without any >>> interaction with dhclient or the static interface configuration. In the >>> mode where you only want an LLA if there isn't another address it's a >>> simple matter of watching the routing socket for messages and a) >>> removing the LLA if an IPv4 address other than 0.0.0.0 is configured on >>> the interface and b) (re)starting the process of obtaining an LLA when >>> all other addresses have been removed. The daemon should be listening >>> to the routing socket anyway because it should only run when the >>> interface has link which requires it to exit when the link goes down >>> similar to dhclient. I really need to go look at the code and see what >>> you're doing now. :) >> Well, I'm doing just that...except it's not the routing socket but the >> netdev filter of the kqueue system. Could be change to the routing >> socket. > > It looks like you'd need to switch to the routing socket to be able to > make decisions based on address changes, but the basic flow should be > the same. > It is doing decisions based on address changes... The difference is that instead of doing a read each time something arrives at the routing socket it just refreshes its data on whats on the interface when an address event takes place and then makes a descisions. Yes, you could see this as a potential race condition, but, it doesn't care if it was an address removal or address addition event that triggered it, it will do the same logic that should eliminate any race condition. However, I might change it to a routing socket anyway, haven't really decided yet. Fredrik Lindberg From owner-freebsd-net@FreeBSD.ORG Fri Aug 25 06:49:47 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A9D7F16A4DF; Fri, 25 Aug 2006 06:49:47 +0000 (UTC) (envelope-from fli+freebsd-net@shapeshifter.se) Received: from mx1.h3q.net (manticore.shapeshifter.se [212.37.5.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C84643D45; Fri, 25 Aug 2006 06:49:47 +0000 (GMT) (envelope-from fli+freebsd-net@shapeshifter.se) Received: from localhost (localhost [127.0.0.1]) by mx1.h3q.net (Postfix) with ESMTP id 1FE9A1A751; Fri, 25 Aug 2006 08:49:46 +0200 (CEST) Received: from mx1.h3q.net ([127.0.0.1]) by localhost (mx1.h3q.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43593-06; Fri, 25 Aug 2006 08:49:11 +0200 (CEST) Received: from [192.168.1.100] (217-208-33-252-o926.tbon.telia.com [217.208.33.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.h3q.net (Postfix) with ESMTP id 726B91A72A; Fri, 25 Aug 2006 08:49:11 +0200 (CEST) Message-ID: <44EE9D66.80105@shapeshifter.se> Date: Fri, 25 Aug 2006 08:49:10 +0200 From: Fredrik Lindberg User-Agent: Thunderbird 1.5.0.4 (X11/20060727) MIME-Version: 1.0 To: PM Lashley References: <72BA6AF827AADB0CFEB845DA@2EEC3F7CCB6B8A97580F632A> In-Reply-To: <72BA6AF827AADB0CFEB845DA@2EEC3F7CCB6B8A97580F632A> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at h3q.net Cc: freebsd-net@freebsd.org, Doug Barton Subject: Re: Zeroconfig and Multicast DNS 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, 25 Aug 2006 06:49:47 -0000 PM Lashley wrote: > >> > But service discovery will often have a non-.local domain; so I >> think we >> > need to allow PTR/SVC/TXT lookups in any domain. (Or possibly anything >> > outside in-addr.arpa. Given the existence of the .local domain, I don't >> > see any utility in advertising a service in an in-addr.arpa domain. I'm >> > sure somebody will post an example if I'm just being short-sighted >> here...) >> >> As you said above SD is not only for mDNS. SD over mDNS should be in the >> .local domain. A SD browser should go through the normal nss environment >> to do its searching and not directly consult the mDNS API for all of its >> queries. Under normal circumstances queries for SD records in existing >> TLDs should be looked up just as any other DNS record. > > No, I don't think that there's any good reason to restrict mDNS service > discovery to .local; when you're using some other domain on the LAN, you > still want to easily do the dynamic service advertisement, even if the A > records are being handled by a traditional unicast DNS server and static > IP allocation. Well, this would cause an authority conflict if it's on by default as anyone on the local network would be able to announce SD records in a domain they do not have authority over. Do do SD updates to an DNS zone you would need to enable dynamic updates on that name server, just as the Service Discovery specifications says. Some quotes from draft-cheshire-dnsext-dns-sd.txt The part of the name may be "local" (meaning "perform the query using link-local multicast) or it may be learned through some other mechanism, such as the DHCP "Domain" option (option code 15) [RFC 2132] or the DHCP "Domain Search" option (option code 119) [RFC 3397]. Service discovery requires a central aggregation server. DNS already has one: It's called a DNS server. Service discovery requires a service registration protocol. DNS already has one: It's called DNS Dynamic Update. Service discovery requires a query protocol DNS already has one: It's called DNS. Service discovery requires security mechanisms. DNS already has security mechanisms: DNSSEC. Service discovery requires a multicast mode for ad-hoc networks. Zeroconf environments already require a multicast-based DNS-like name lookup protocol for mapping host names to addresses, so it makes sense to let one multicast-based protocol do both jobs. I don't say that we shouldn't support it, but it should not be on by default. And it will actually boil down to what the mdns nss module allows. > >> > Not entirely. It is also a syntactic/semantic issue in the config file >> > design. There's a choice between whether there's an implicit "ignore >> > this if the necessary protocol isn't available" or some sort of >> > conditional block to explicitly say 'if condition X, then apply the >> > following set of options'. The later is potentially more powerful. >> >> Yes, I agree. A user might want to advertise a record only if a >> certain condition is met, however I think we should be careful >> not to create a too complex syntax. >> The mdns.conf must be simple enough so that an average user is >> able to edit it without too much knowledge. >> We really do not want to turn in into something similar to named.conf, >> more /etc/hosts on steroids. > > We can define the basic conditional block and some simple conditional > tests for things like 'is interface X currently supporting IPv4?' or 'is > interface X a point-to-point link?'; and possibly a 'for each interface globs>'. And then add condition tests as necessary/desirable > later. > Yeah sure, but it's all about creating a logical and easy syntax... Fredrik Lindberg From owner-freebsd-net@FreeBSD.ORG Fri Aug 25 13:46:55 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 631E216A4DF for ; Fri, 25 Aug 2006 13:46:55 +0000 (UTC) (envelope-from pp@pp.dyndns.biz) Received: from mxfep01.bredband.com (mxfep01.bredband.com [195.54.107.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id AF97243D68 for ; Fri, 25 Aug 2006 13:46:48 +0000 (GMT) (envelope-from pp@pp.dyndns.biz) Received: from gatekeeper.pp.dyndns.biz ([85.224.219.119] [85.224.219.119]) by mxfep01.bredband.com with ESMTP id <20060825134644.CNFR5813.mxfep01.bredband.com@gatekeeper.pp.dyndns.biz> for ; Fri, 25 Aug 2006 15:46:44 +0200 Received: from phobos ([192.168.69.67]) by gatekeeper.pp.dyndns.biz (8.13.6/8.13.6) with ESMTP id k7PDkZpl059025 for ; Fri, 25 Aug 2006 15:46:38 +0200 (CEST) (envelope-from pp@pp.dyndns.biz) From: "Morgan" Sender: "pp" To: Date: Fri, 25 Aug 2006 15:46:22 +0200 Message-ID: <02df01c6c84c$dcd564c0$4345a8c0@phobos> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AcbITNmeCkpUSHnHQkCdpFt1afqrVw== Subject: Optimizing a high-latency connection 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, 25 Aug 2006 13:46:55 -0000 Hi. I'm trying som file transfers across the globe. The RTT is almost 400ms and the transfer rate is painfully slow. There are 24 router hops on the path and I assume most of the problem is there but I wonder if there are any sysctl variables I can trim on my side to help this problem slightly? I seem to understand that there need to be an ACK received for at least every other packet or at least every 100ms for the data flow to proceed uninterrupted but I'm no expert in this field so please correct me if I'm wrong. Assuming this IS correct, are there any sysctl variables I can optimize to change this behaviour or will that affect low latency connections negatively. Any other suggestions? Regards Morgan From owner-freebsd-net@FreeBSD.ORG Fri Aug 25 14:19:30 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5C83216A4DF for ; Fri, 25 Aug 2006 14:19:30 +0000 (UTC) (envelope-from pete@he.iki.fi) Received: from silver.he.iki.fi (helenius.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8E71143D4C for ; Fri, 25 Aug 2006 14:19:28 +0000 (GMT) (envelope-from pete@he.iki.fi) Received: from localhost (localhost [127.0.0.1]) by silver.he.iki.fi (Postfix) with ESMTP id C5993BBFD; Fri, 25 Aug 2006 17:19:25 +0300 (EEST) Received: from silver.he.iki.fi ([127.0.0.1]) by localhost (silver.he.iki.fi [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u4JpPvoz6Dm6; Fri, 25 Aug 2006 17:19:23 +0300 (EEST) Received: from [IPv6:2001:670:84:0:39bb:8797:1025:e0cd] (unknown [IPv6:2001:670:84:0:39bb:8797:1025:e0cd]) by silver.he.iki.fi (Postfix) with ESMTP; Fri, 25 Aug 2006 17:19:20 +0300 (EEST) Message-ID: <44EF06E9.1070003@he.iki.fi> Date: Fri, 25 Aug 2006 17:19:21 +0300 From: Petri Helenius User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Morgan References: <02df01c6c84c$dcd564c0$4345a8c0@phobos> In-Reply-To: <02df01c6c84c$dcd564c0$4345a8c0@phobos> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Optimizing a high-latency connection 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, 25 Aug 2006 14:19:30 -0000 Increase sendspace an recvspace depending which way your data is going: net.inet.tcp.sendspace: 57344 net.inet.tcp.recvspace: 256000 TCP window scaling is enabled by default nowadays if I remember correctly. Pete Morgan wrote: > Hi. > > I'm trying som file transfers across the globe. The RTT is almost 400ms and > the transfer rate is painfully slow. There are 24 router hops on the path > and I assume most of the problem is there but I wonder if there are any > sysctl variables I can trim on my side to help this problem slightly? I seem > to understand that there need to be an ACK received for at least every other > packet or at least every 100ms for the data flow to proceed uninterrupted > but I'm no expert in this field so please correct me if I'm wrong. Assuming > this IS correct, are there any sysctl variables I can optimize to change > this behaviour or will that affect low latency connections negatively. Any > other suggestions? > > Regards > Morgan > > > _______________________________________________ > 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 Fri Aug 25 15:13:30 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0D96A16A4DE; Fri, 25 Aug 2006 15:13:30 +0000 (UTC) (envelope-from patl+freebsd@volant.org) Received: from smtp.volant.org (gate.volant.org [207.111.218.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id B0A0E43D5F; Fri, 25 Aug 2006 15:13:21 +0000 (GMT) (envelope-from patl+freebsd@volant.org) Received: from adsl-065-081-071-131.sip.gnv.bellsouth.net ([65.81.71.131] helo=[192.168.1.167]) by smtp.volant.org with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34 (FreeBSD)) id 1GGdQH-000AbT-EA; Fri, 25 Aug 2006 08:16:45 -0700 Date: Fri, 25 Aug 2006 11:12:29 -0400 From: Pat Lashley To: Fredrik Lindberg Message-ID: In-Reply-To: <44EE9D66.80105@shapeshifter.se> References: <72BA6AF827AADB0CFEB845DA@2EEC3F7CCB6B8A97580F632A> <44EE9D66.80105@shapeshifter.se> X-Mailer: Mulberry/4.0.0 (Mac OS X) MIME-Version: 1.0 X-Scan-Signature: 5a9f0aa7631eaf24b05a19f367ec35b66bbb353d X-Spam-User: nobody X-Spam-Score: -4.3 (----) X-Spam-Score-Int: -42 X-Spam-Report: This mail has matched the spam-filter tests listed below. See http://spamassassin.org/tag/ for details about the specific tests reported. In general, the higher the number of total points, the more likely that it actually is spam. (The 'required' number of points listed below is the arbitrary number above which the message is normally considered spam.) Content analysis details: (-4.3 points total, 5.0 required) 0.1 HTML_MESSAGE BODY: HTML included in message 0.1 HTML_FONTCOLOR_RED BODY: HTML font color is red -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.4 AWL AWL: Auto-whitelist adjustment Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, Doug Barton Subject: Re: Zeroconfig and Multicast DNS 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, 25 Aug 2006 15:13:30 -0000 > > No, I don't think that there's any good reason to restrict mDNS service > > discovery to .local; when you're using some other domain on the LAN, you > > still want to easily do the dynamic service advertisement, even if the A > > records are being handled by a traditional unicast DNS server and static > > IP allocation. > > Well, this would cause an authority conflict if it's on by default as > anyone on the local network would be able to announce SD records in > a domain they do not have authority over. The normal use of SD requires the ability of non-privileged users to announce services on the FQDN of the host upon which they are running. (Think iTunes playlist sharing.) > Do do SD updates to an DNS zone you would need to enable dynamic updates > on that name server, just as the Service Discovery specifications says. What makes you think that there even IS a unicast DNS server for the (sub)domain in question? > Some quotes from draft-cheshire-dnsext-dns-sd.txt > > The part of the name may be "local" (meaning "perform the > query using link-local multicast) or it may be learned through some > other mechanism, such as the DHCP "Domain" option (option code 15) > [RFC 2132] or the DHCP "Domain Search" option (option code 119) > [RFC 3397]. > > Service discovery requires a central aggregation server. > DNS already has one: It's called a DNS server. > > Service discovery requires a service registration protocol. > DNS already has one: It's called DNS Dynamic Update. > > Service discovery requires a query protocol > DNS already has one: It's called DNS. > > Service discovery requires security mechanisms. > DNS already has security mechanisms: DNSSEC. > > Service discovery requires a multicast mode for ad-hoc networks. > Zeroconf environments already require a multicast-based DNS-like > name lookup protocol for mapping host names to addresses, so it > makes sense to let one multicast-based protocol do both jobs. > > I don't say that we shouldn't support it, but it should not be on by > default. And it will actually boil down to what the mdns nss module > allows. I agree that it should not be on by default. But there should be one simple knob in rc.conf to cause service advertisements to be published for both .local and the host domain. Any thing more complex would require editing mdns.conf. -Pat From owner-freebsd-net@FreeBSD.ORG Fri Aug 25 15:17:00 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6C2F716A4DD for ; Fri, 25 Aug 2006 15:17:00 +0000 (UTC) (envelope-from brett@lariat.net) Received: from lariat.net (lariat.net [65.122.236.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id C834843D46 for ; Fri, 25 Aug 2006 15:16:59 +0000 (GMT) (envelope-from brett@lariat.net) Received: from Anne (IDENT:ppp1000.lariat.net@lariat.net [65.122.236.2]) by lariat.net (8.9.3/8.9.3) with ESMTP id JAA01626; Fri, 25 Aug 2006 09:16:51 -0600 (MDT) X-message-flag: Warning! Use of Microsoft Outlook renders your system susceptible to Internet worms. Message-Id: <7.0.1.0.2.20060825091302.074f8008@lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 25 Aug 2006 09:16:49 -0600 To: Archie Cobbs , Julian Elischer From: Brett Glass In-Reply-To: <7.0.1.0.2.20060813182130.06f54060@lariat.net> References: <7.0.1.0.2.20060810201735.067258b0@lariat.net> <44DBF2BB.5080202@micom.mng.net> <7.0.1.0.2.20060810212047.073f0078@lariat.net> <44DBFC05.6080804@elischer.org> <7.0.1.0.2.20060810220804.08de8568@lariat.net> <44DCB4D8.4020901@elischer.org> <44DF51C1.8000306@dellroad.org> <7.0.1.0.2.20060813182130.06f54060@lariat.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: net@freebsd.org Subject: Re: Big PPTP server 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, 25 Aug 2006 15:17:00 -0000 Archie, Julian: Just wanted to ask about the feasibility of the following idea. Would it be possible to use the Netgraph PPTP node, in combination with Brian Somers' userland PPP implementation, to make a PPTP server? It would work similarly to FreeBSD's "pppoed", which uses the Netgraph PPPoE node. This would provide the full feature set of the userland PPP (including dynamic creation of Netgraph nodes, the ability to call out to shell scripts, etc.) together with your PPTP implementation. How hard would it be to cobble this together, starting with the code for pppoed? --Brett Glass From owner-freebsd-net@FreeBSD.ORG Fri Aug 25 15:49:14 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7FBF516A4DA for ; Fri, 25 Aug 2006 15:49:14 +0000 (UTC) (envelope-from rajkumars@gmail.com) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2073943D67 for ; Fri, 25 Aug 2006 15:49:04 +0000 (GMT) (envelope-from rajkumars@gmail.com) Received: by nz-out-0102.google.com with SMTP id 13so596969nzn for ; Fri, 25 Aug 2006 08:49:04 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=dSjp/myRpoKP+TrcIHVUW2qkuVV7STtOZWby/91W+yZ7PzJZnK8545iEitsNXzYhPs8qw86g1bvZwZtHkhu517NDX/2bTNrgpROntPzTdU5K2AkShlYqa2RPeiWDOcujvItPwHE0IkKEPeD6cjVBUEHzjL4fk8yomIH7Wkhl+N8= Received: by 10.65.114.11 with SMTP id r11mr3920125qbm; Fri, 25 Aug 2006 08:49:04 -0700 (PDT) Received: by 10.65.248.1 with HTTP; Fri, 25 Aug 2006 08:49:04 -0700 (PDT) Message-ID: <64de5c8b0608250849p2912457cs84c227cc914d1f10@mail.gmail.com> Date: Fri, 25 Aug 2006 21:19:04 +0530 From: "Rajkumar S" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Netgraph plumbing question 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, 25 Aug 2006 15:49:14 -0000 Hi, In the ng_split node is it possible to merge 2 incoming streams into mixed, while all packets received at mixed goes via out? If merge node does not support that, is there any other way to get the same result? regards, raj From owner-freebsd-net@FreeBSD.ORG Fri Aug 25 16:16:37 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2B21116A4DF for ; Fri, 25 Aug 2006 16:16:37 +0000 (UTC) (envelope-from archie@dellroad.org) Received: from smtp.omnis.com (smtp.omnis.com [216.239.128.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id ADC1743D69 for ; Fri, 25 Aug 2006 16:16:36 +0000 (GMT) (envelope-from archie@dellroad.org) Received: from postoffice.omnis.com (mail-hub-2.int.omnis.com [10.0.0.37]) by smtp.omnis.com (Postfix) with ESMTP id C905D1B302; Fri, 25 Aug 2006 09:16:35 -0700 (PDT) Received: from [10.3.2.11] (fw.awarix.com [70.43.89.155]) by smtp-relay.omnis.com (Postfix) with ESMTP id 403191880C3E; Fri, 25 Aug 2006 09:16:35 -0700 (PDT) Message-ID: <44EF2262.7020009@dellroad.org> Date: Fri, 25 Aug 2006 11:16:34 -0500 From: Archie Cobbs User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050715) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brett Glass References: <7.0.1.0.2.20060810201735.067258b0@lariat.net> <44DBF2BB.5080202@micom.mng.net> <7.0.1.0.2.20060810212047.073f0078@lariat.net> <44DBFC05.6080804@elischer.org> <7.0.1.0.2.20060810220804.08de8568@lariat.net> <44DCB4D8.4020901@elischer.org> <44DF51C1.8000306@dellroad.org> <7.0.1.0.2.20060813182130.06f54060@lariat.net> <7.0.1.0.2.20060825091302.074f8008@lariat.net> In-Reply-To: <7.0.1.0.2.20060825091302.074f8008@lariat.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Julian Elischer , net@freebsd.org Subject: Re: Big PPTP server 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, 25 Aug 2006 16:16:37 -0000 Brett Glass wrote: > Just wanted to ask about the feasibility of the following idea. Would it > be possible to use the Netgraph PPTP node, in combination with Brian > Somers' userland PPP implementation, to make a PPTP server? It would > work similarly to FreeBSD's "pppoed", which uses the Netgraph PPPoE > node. This would provide the full feature set of the userland PPP > (including dynamic creation of Netgraph nodes, the ability to call out > to shell scripts, etc.) together with your PPTP implementation. How hard > would it be to cobble this together, starting with the code for pppoed? Sure it's feasible.. it's just a SMOP :-) (small matter of programming). The ng_pptpgre node handles the "data packet" level of PPTP, but most of the complexity in PPTP is in the higher level protocol for setup and teardown. You'd have to get that in there somehow. Two (different) examples of such code are in (1) mpd and (2) libpdel. The latter is newer and cleaner but might be harder to merge. -Archie __________________________________________________________________________ Archie Cobbs * CTO, Awarix * http://www.awarix.com From owner-freebsd-net@FreeBSD.ORG Fri Aug 25 17:33:51 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F408D16A4E2 for ; Fri, 25 Aug 2006 17:33:50 +0000 (UTC) (envelope-from brett@lariat.net) Received: from lariat.net (lariat.net [65.122.236.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 72DF843D6E for ; Fri, 25 Aug 2006 17:33:45 +0000 (GMT) (envelope-from brett@lariat.net) Received: from Anne (IDENT:ppp1000.lariat.net@lariat.net [65.122.236.2]) by lariat.net (8.9.3/8.9.3) with ESMTP id LAA05136; Fri, 25 Aug 2006 11:33:34 -0600 (MDT) X-message-flag: Warning! Use of Microsoft Outlook renders your system susceptible to Internet worms. Message-Id: <7.0.1.0.2.20060825110346.075161f0@lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 25 Aug 2006 11:33:36 -0600 To: Archie Cobbs From: Brett Glass In-Reply-To: <44EF2262.7020009@dellroad.org> References: <7.0.1.0.2.20060810201735.067258b0@lariat.net> <44DBF2BB.5080202@micom.mng.net> <7.0.1.0.2.20060810212047.073f0078@lariat.net> <44DBFC05.6080804@elischer.org> <7.0.1.0.2.20060810220804.08de8568@lariat.net> <44DCB4D8.4020901@elischer.org> <44DF51C1.8000306@dellroad.org> <7.0.1.0.2.20060813182130.06f54060@lariat.net> <7.0.1.0.2.20060825091302.074f8008@lariat.net> <44EF2262.7020009@dellroad.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: Julian Elischer , net@freebsd.org Subject: Re: Big PPTP server 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, 25 Aug 2006 17:33:51 -0000 At 10:16 AM 8/25/2006, Archie Cobbs wrote: >The ng_pptpgre node handles the "data packet" level of PPTP, but most >of the complexity in PPTP is in the higher level protocol for setup >and teardown. You'd have to get that in there somehow. I suppose that the call control facility could be implemented in the kernel, but it's probably better to handle it in user space, since the call manager behaves like any other program that listens on a TCP socket. If call management is done in user space, it's necessary to keep tabs on all the calls in one of three ways. mpd and pppoed use one master process that tracks them all. The alternatives are to spawn separate processes to track each one, as PoPToP does (high overhead!), or to go threaded, with one thread per call (probably the most efficient way to go). If the daemon were to use one master process as mpd does, much of the code from mpd could be reused. The state machine could be lifted from mpd nearly verbatim. Brian Somers, are you monitoring this list? Are there any potential pitfalls I'm overlooking here? Would patches be needed in ppp(8)? --Brett From owner-freebsd-net@FreeBSD.ORG Fri Aug 25 17:40:21 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B0DA616A4E9 for ; Fri, 25 Aug 2006 17:40:21 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id E320943D58 for ; Fri, 25 Aug 2006 17:40:00 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from mac.com (smtpin03-en2 [10.13.10.148]) by smtpout.mac.com (Xserve/8.12.11/smtpout02/MantshX 4.0) with ESMTP id k7PHdvpY009134; Fri, 25 Aug 2006 10:39:58 -0700 (PDT) Received: from [17.214.14.142] (a17-214-14-142.apple.com [17.214.14.142]) (authenticated bits=0) by mac.com (Xserve/smtpin03/MantshX 4.0) with ESMTP id k7PHdrrm012085; Fri, 25 Aug 2006 10:39:56 -0700 (PDT) In-Reply-To: <961EF4A5A611779A598DE704@garrett.local> References: <20060823221835.GA28978@lor.one-eyed-alien.net> <23D2619F6BACE4E728178EE5@garrett.local> <44ED3BD1.3030206@shapeshifter.se> <44EDA9A5.2050108@shapeshifter.se> <44EDBDD0.4050000@shapeshifter.se> <7CC9AC69410B69EBD31122E4@garrett.local> <44EDDB8C.9090504@shapeshifter.se> <0EC404BA0CA363942D250766@garrett.local> <20060824182640.GA37561@lor.one-eyed-alien.net> <22D92E8D-DE18-4883-8E77-5567AF63DFE0@mac.com> <961EF4A5A611779A598DE704@garrett.local> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5D1A78C8-674C-428D-83B6-3CD2F654A69B@mac.com> Content-Transfer-Encoding: 7bit From: Chuck Swiger Date: Fri, 25 Aug 2006 10:39:53 -0700 To: Pat Lashley X-Mailer: Apple Mail (2.752.2) X-Brightmail-Tracker: AAAAAQAAA+k= X-Language-Identified: TRUE Cc: freebsd-net@freebsd.org Subject: Re: Zeroconfig and Multicast DNS 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, 25 Aug 2006 17:40:21 -0000 On Aug 24, 2006, at 6:29 PM, Pat Lashley wrote: >> Mac OS X implements media sense where the hardware and driver >> support >> it. When the network media indicates that it has been connected, >> the >> autoconfiguration process begins again, and attempts to re-use the >> previously assigned Link-Local address. When the network media >> indicates that it has been disconnected, the system waits four >> seconds before de-configuring the Link-Local address and subnet. If >> the connection is restored before that time, the autoconfiguration >> process begins again. If the connection is not restored before that >> time, the system chooses another interface to autoconfigure. > > But OS X also only supports Zeroconf on one interface at a time. We > Can Do Better. I believe Apple creates /32 host-specific routes for Zeroconf traffic on the other interfaces, if seen. That may actually just be the normal ARP-handling code in operation rather than Zeroconf, per se, although Apple's implementation of ARP is Zeroconf-compliant in terms of timing, setting "sender IP address" (aka arphdr->ar_spa) field to all zeroes to avoid polluting other systems' ARP caches, announcing & defending LLA IP reservations, etc. I would be entirely happy if FreeBSD could do better than MacOS with regard to this matter, but my observation suggests that the dudes working on this at Apple have a working implementation which is becoming widely used in userland applications for things like printer discovery on unconfigured LANs, chat, music sharing on the LAN (via iTunes), and for which the potential problems involved with things like multihomed machines are somewhat well understood. >>> There still remains the possibility of multiple distinct hosts >>> having the same LLA IP address on separate local links; each >>> attached to a separate interface. In practice that situation should >>> be sufficiently rare that we can afford to ignore it until someone >>> comes up with some clever way to handle it. (Or we all move to IPv6 >>> and it becomes moot.) >> >> See section 4 of RFC-3927. > > No, that covers merging two previously disjoint networks; I don't > think that it is intended to handle the case of a multi-homed host > that is connected to both of them while keeping them separate. That section covers the merging of two previously disjoint networks, agreed; for the case of connecting a multihomed host which is bridging them, this section is entirely relevant. Otherwise, LLA only deals with one collision domain (or link, etc) by definition, and one requirement which is relevant to a multihomed host is that it must ensure that the system assigns a different LLA to each interface. The probability that you will have the same LLA appear on two distinct subnets is a variant of the "birthday paradox"; there's a 10% chance of a collision with ~120 hosts, and a 50% chance of a collision with 300, assuming the code copied below is right. -- -Chuck #!/usr/bin/env python """This program computes the probability that two (or more) hosts will have an address collision. Set ip_range to 365 and this computes the 'birthday paradox'.""" ip_range = 65024 #ip_range = 365 prob = 0.0 number_of_hosts = 1 def unique(n): """Given n distinct hosts with randomly distributed addresses within the ip_range, return the probability that all will be assigned a unique address.""" if n == 1: return 1.0 else: return unique(n - 1) * (ip_range - (n - 1)) / ip_range while (prob < .5): prob = 1.0 - unique(number_of_hosts) print "Number of hosts: %d" % number_of_hosts print "Probability of IP collision: %0.4f" % prob number_of_hosts += 1 From owner-freebsd-net@FreeBSD.ORG Fri Aug 25 19:26:48 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0D14D16A4DA for ; Fri, 25 Aug 2006 19:26:48 +0000 (UTC) (envelope-from patl+freebsd@volant.org) Received: from smtp.volant.org (gate.volant.org [207.111.218.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A42F43D6D for ; Fri, 25 Aug 2006 19:26:17 +0000 (GMT) (envelope-from patl+freebsd@volant.org) Received: from adsl-065-081-071-131.sip.gnv.bellsouth.net ([65.81.71.131] helo=[192.168.1.167]) by smtp.volant.org with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34 (FreeBSD)) id 1GGhMn-000CvP-Qh; Fri, 25 Aug 2006 12:29:34 -0700 Date: Fri, 25 Aug 2006 15:24:55 -0400 From: Pat Lashley To: Chuck Swiger Message-ID: <17A034A7E9A76AA9FD37FC11@garrett.local> In-Reply-To: <5D1A78C8-674C-428D-83B6-3CD2F654A69B@mac.com> References: <20060823221835.GA28978@lor.one-eyed-alien.net> <23D2619F6BACE4E728178EE5@garrett.local> <44ED3BD1.3030206@shapeshifter.se> <44EDA9A5.2050108@shapeshifter.se> <44EDBDD0.4050000@shapeshifter.se> <7CC9AC69410B69EBD31122E4@garrett.local> <44EDDB8C.9090504@shapeshifter.se> <0EC404BA0CA363942D250766@garrett.local> <20060824182640.GA37561@lor.one-eyed-alien.net> <22D92E8D-DE18-4883-8E77-5567AF63DFE0@mac.com> <961EF4A5A611779A598DE704@garrett.local> <5D1A78C8-674C-428D-83B6-3CD2F654A69B@mac.com> X-Mailer: Mulberry/4.0.0 (Mac OS X) MIME-Version: 1.0 X-Scan-Signature: 9147617073217ecfb3d211acd5b6c66e5c05ce85 X-Spam-User: nobody X-Spam-Score: -4.3 (----) X-Spam-Score-Int: -42 X-Spam-Report: This mail has matched the spam-filter tests listed below. See http://spamassassin.org/tag/ for details about the specific tests reported. In general, the higher the number of total points, the more likely that it actually is spam. (The 'required' number of points listed below is the arbitrary number above which the message is normally considered spam.) Content analysis details: (-4.3 points total, 5.0 required) 0.1 HTML_MESSAGE BODY: HTML included in message 0.1 HTML_FONTCOLOR_RED BODY: HTML font color is red -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.4 AWL AWL: Auto-whitelist adjustment Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: Zeroconfig and Multicast DNS 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, 25 Aug 2006 19:26:48 -0000 > I believe Apple creates /32 host-specific routes for Zeroconf traffic on the > other interfaces, if seen. That may actually just be the normal ARP-handling > code in operation rather than Zeroconf, per se, although Apple's > implementation of ARP is Zeroconf-compliant in terms of timing, setting > "sender IP address" (aka arphdr->ar_spa) field to all zeroes to avoid > polluting other systems' ARP caches, announcing & defending LLA IP > reservations, etc. As ours should be. The only part of that that should be affected by whether or not LLA is enabled is the announcing and defending portion. > I would be entirely happy if FreeBSD could do better than MacOS with regard to > this matter, but my observation suggests that the dudes working on this at > Apple have a working implementation which is becoming widely used in userland > applications for things like printer discovery on unconfigured LANs, chat, > music sharing on the LAN (via iTunes), and for which the potential problems > involved with things like multihomed machines are somewhat well understood. Apple's primary consumer base for Zeroconf systems doesn't normally have to deal with multi-homed systems; so it probably isn't much of a priority for them. They also need to maintain a higher level of easy configurability by non-technical users. FreeBSD's target user base leans towards the more technical and the more server-oriented. I don't know any of the people working on Zeroconf at Apple; and have no idea how well they have investigated the issues surrounding multi-homed machines. I suspect that the decision was made fairly early to only support it on one interface at a time. That certainly made it easier to concentrate on getting the more common one-interface scenario to work correctly. But they, and others working on Zeroconf, have pretty well identified the one-interface issues and come up with solutions; so we don't have to duplicate that research. Which means that we're free to look at the implications for multi-homed machines. I would agree that our first implementation should focus on the single-interface situation; but we should keep the multi-homed machines in mind while designing it. It's OK if we say "you can enable it on more than one interface; but we're not going to guarantee that you won't run into problems." > >> See section 4 of RFC-3927. > > > > No, that covers merging two previously disjoint networks; I don't > > think that it is intended to handle the case of a multi-homed host > > that is connected to both of them while keeping them separate. > > That section covers the merging of two previously disjoint networks, agreed; > for the case of connecting a multihomed host which is bridging them, this > section is entirely relevant. Otherwise, LLA only deals with one collision > domain (or link, etc) by definition, and one requirement which is relevant to > a multihomed host is that it must ensure that the system assigns a different > LLA to each interface. Yes, as you say, it is relevant if the host is bridging, but not if it is treating them as separate subnets. Which requires separate LLA negotiations; but I don't see where section 4 requires them to have separate IP addresses. (It's probably a good idea; but it doesn't seem to be required by section 4.) Multi-homed hosts are covered in section 3. Which is basically a discussion of some of the problems that are likely to be encountered; without mandating (or forbidding) any particular solution. Section 3.4 does require separate LL Ip addresses IF the interfaces are on the same link. But, as they point out, the easiest method of avoiding auto-immune response is to run the algorithm separately for each interface. In which case no special action need be taken to determine whether they are on the same link, or to avoid requesting the same address; the normal LLA negotiation will ensure that one of them wins and the other picks another address. > The probability that you will have the same LLA appear on two distinct subnets > is a variant of the "birthday paradox"; there's a 10% chance of a collision > with ~120 hosts, and a 50% chance of a collision with 300, assuming the code > copied below is right. Not exactly. I think that that computes the probability that a newly attached host will pick an initial IP address that is already in use. To apply it to a pair of networks, you need to deal with how many hosts are on each network and the fact that within each network, the IPs are already guaranteed to be unique. So, given two networks, one with N hosts, the other with M; for the first host in N, the chance of collision is M / 65024; for the second it is M / 65023; etc. (Each host in N reduces the available address space from which the other N-hosts may be chosen; it does not increase the number of hosts that they must be compared against.) The total probability is the sum of the probabilities for each of the N hosts. I think that you;ll find that the minimum number to produce a 50% probability will require that both networks have the same number of hosts (or differ by only one); and that as the populations become unbalanced, the total required rises fairly rapidly. (E.g., if N is 1, M must be 32512 for a total of 32513.) -Pat From owner-freebsd-net@FreeBSD.ORG Fri Aug 25 19:40:54 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2980416A4DE; Fri, 25 Aug 2006 19:40:54 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from sccmmhc91.asp.att.net (sccmmhc91.asp.att.net [204.127.203.211]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5566E43D5C; Fri, 25 Aug 2006 19:40:52 +0000 (GMT) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net ([12.207.12.9]) by sccmmhc91.asp.att.net (sccmmhc91) with ESMTP id <20060825194040m910085kvge>; Fri, 25 Aug 2006 19:40:51 +0000 Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.13.6/8.13.6) with ESMTP id k7PJeW0K050636; Fri, 25 Aug 2006 14:40:32 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.13.6/8.13.6/Submit) id k7PJeSqm050635; Fri, 25 Aug 2006 14:40:28 -0500 (CDT) (envelope-from brooks) Date: Fri, 25 Aug 2006 14:40:27 -0500 From: Brooks Davis To: "JINMEI Tatuya / ?$B?@L@C#:H" Message-ID: <20060825194027.GA50432@lor.one-eyed-alien.net> References: <44ECB0F2.9040300@FreeBSD.org> <44ECBB61.9020808@shapeshifter.se> <5D7785ADC030FEBFB9A5E69D@garrett.local> <44ED8266.1060303@shapeshifter.se> <7C6CDF1CB0BC58A6ADE1FCA8@garrett.local> <44EDCEC2.7060109@shapeshifter.se> <93381966E13B960D4ACFF05C@garrett.local> <44EDF116.9050106@shapeshifter.se> <20060824184228.GC37561@lor.one-eyed-alien.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fUYQa+Pmc3FrFX/N" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11 Cc: freebsd-net@freebsd.org, Pat Lashley , Doug Barton , Fredrik Lindberg Subject: Re: Zeroconfig and Multicast DNS 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, 25 Aug 2006 19:40:54 -0000 --fUYQa+Pmc3FrFX/N Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 25, 2006 at 10:35:03AM +0900, JINMEI Tatuya / ?$B?@L@C#:H wrote: > >>>>> On Thu, 24 Aug 2006 13:42:29 -0500,=20 > >>>>> Brooks Davis said: >=20 > >> Um...I'm not sure if this is even possible. Let's forget mDNS and > >> go back to basic IP. > >> Say a multi-homed host has two interfaces both configured with an > >> address in the rage 169.254/16, say 169.254.1.1 and 169.254.2.1 and > >> it wants to initiate a connection to 169.254.3.1, how on earth should > >> it be able to tell on which side 3.1 is located? There might even be > >> one 3.1 on both side that could be completely different hosts. >=20 > > You probably would need an extension similiar to the one for IPv6 LLAs. > > i.e. the %bge0 in fe80::2e0:81ff:fe31:9f00%bge0. >=20 > (I've not followed the discussion closely, so my apologize in advance > if this message reacts to an off-topic.) >=20 > Note that the '%bge0' notation works well thanks to the sin6_scope_id > field of the sockaddr_in6{} structure. Since sockaddr_in{} doesn't > have such an additional member to solve the ambiguity, the extension > to the IPv4 addresses would not be that trivial. Thanks for the response. That makes sense. I think due to the sin_zero member in sockaddr_in{} we could fix this without breaking ABI compatability if we shrunk sin_zero appropriatly (or for API compatability created a union and #defined sin_zero) and then added a reference to the interface index. That would have the advantage of also letting us clean up the abuse of sin_zero to store the interface name in ip_divert.c. -- Brooks --fUYQa+Pmc3FrFX/N Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFE71IqXY6L6fI4GtQRAm6XAJ0aMc/axm6bB1blZI2cWw7Ly5jWMwCePXFq kHJDif1Zvrxz7PU/VU6CCi0= =ION5 -----END PGP SIGNATURE----- --fUYQa+Pmc3FrFX/N-- From owner-freebsd-net@FreeBSD.ORG Fri Aug 25 20:19:07 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A65F016A4DE for ; Fri, 25 Aug 2006 20:19:07 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.185]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3386F43D49 for ; Fri, 25 Aug 2006 20:19:07 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from mac.com (smtpin02-en2 [10.13.10.147]) by smtpout.mac.com (Xserve/8.12.11/smtpout15/MantshX 4.0) with ESMTP id k7PKJ6ss014125; Fri, 25 Aug 2006 13:19:07 -0700 (PDT) Received: from [17.214.14.142] (a17-214-14-142.apple.com [17.214.14.142]) (authenticated bits=0) by mac.com (Xserve/smtpin02/MantshX 4.0) with ESMTP id k7PKJ3Pq029923; Fri, 25 Aug 2006 13:19:05 -0700 (PDT) In-Reply-To: <17A034A7E9A76AA9FD37FC11@garrett.local> References: <20060823221835.GA28978@lor.one-eyed-alien.net> <23D2619F6BACE4E728178EE5@garrett.local> <44ED3BD1.3030206@shapeshifter.se> <44EDA9A5.2050108@shapeshifter.se> <44EDBDD0.4050000@shapeshifter.se> <7CC9AC69410B69EBD31122E4@garrett.local> <44EDDB8C.9090504@shapeshifter.se> <0EC404BA0CA363942D250766@garrett.local> <20060824182640.GA37561@lor.one-eyed-alien.net> <22D92E8D-DE18-4883-8E77-5567AF63DFE0@mac.com> <961EF4A5A611779A598DE704@garrett.local> <5D1A78C8-674C-428D-83B6-3CD2F654A69B@mac.com> <17A034A7E9A76AA9FD37FC11@garrett.local> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <71ABACA2-25E0-4B4F-89EA-3A70A98330E9@mac.com> Content-Transfer-Encoding: 7bit From: Chuck Swiger Date: Fri, 25 Aug 2006 13:19:02 -0700 To: Pat Lashley X-Mailer: Apple Mail (2.752.2) X-Brightmail-Tracker: AAAAAQAAA+k= X-Language-Identified: TRUE Cc: freebsd-net@freebsd.org Subject: Re: Zeroconfig and Multicast DNS 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, 25 Aug 2006 20:19:07 -0000 On Aug 25, 2006, at 12:24 PM, Pat Lashley wrote: >> I would be entirely happy if FreeBSD could do better than MacOS >> with regard to >> this matter, but my observation suggests that the dudes working >> on this at >> Apple have a working implementation which is becoming widely used >> in userland >> applications for things like printer discovery on unconfigured >> LANs, chat, >> music sharing on the LAN (via iTunes), and for which the >> potential problems >> involved with things like multihomed machines are somewhat well >> understood. > > Apple's primary consumer base for Zeroconf systems doesn't normally > have to deal with multi-homed systems; so it probably isn't much of > a priority for them. Um, Pat...? All of the laptops Apple sells have ethernet & 802.11 wireless built in and thus are multihomed from day one; all of the desktop & Mac mini systems being sold are ethernet & wireless ready, and I gather that many systems are purchased with the wireless option. Also note that Apple is also shipping pretty much everything they sell with Firewire, which only Sony seems to do on the PC side. > They also need to maintain a higher level of easy configurability > by non-technical users. FreeBSD's target user base leans towards > the more technical and the more server-oriented. Absolutely. LLA & mDNS are targetted for ad-hoc networks which are mostly or entirely unconfigured; FreeBSD's target user base tends to do things like setup servers with fixed IPs and configure networks via DHCP, setting up DNS zones, and so forth. MacOS users have a much greater demand and use for LLA & mDNS than FreeBSD users do; after all, Apple has userland apps which take advantage of this functionality now. > I don't know any of the people working on Zeroconf at Apple; and > have no idea how well they have investigated the issues surrounding > multi-homed machines. Read the first few lines of http://www.faqs.org/rfcs/rfc3927.html, or look at the end: Authors' Addresses Stuart Cheshire Apple Computer, Inc. 1 Infinite Loop Cupertino California 95014, USA Phone: +1 408 974 3207 EMail: rfc@stuartcheshire.org [ ... ] >> That section covers the merging of two previously disjoint >> networks, agreed; >> for the case of connecting a multihomed host which is bridging >> them, this >> section is entirely relevant. Otherwise, LLA only deals with one >> collision >> domain (or link, etc) by definition, and one requirement which is >> relevant to >> a multihomed host is that it must ensure that the system assigns >> a different >> LLA to each interface. >> > Yes, as you say, it is relevant if the host is bridging, but not if > it is treating them as separate subnets. Which requires separate > LLA negotiations; but I don't see where section 4 requires them to > have separate IP addresses. (It's probably a good idea; but it > doesn't seem to be required by section 4.) It's not required in section 4; see section 3, particularly 3.4. > Multi-homed hosts are covered in section 3. Which is basically a > discussion of some of the problems that are likely to be > encountered; without mandating (or forbidding) any particular > solution. > > Section 3.4 does require separate LL Ip addresses IF the interfaces > are on the same link. But, as they point out, the easiest method of > avoiding auto-immune response is to run the algorithm separately > for each interface. In which case no special action need be taken > to determine whether they are on the same link, or to avoid > requesting the same address; the normal LLA negotiation will ensure > that one of them wins and the other picks another address. This draft RFC doesn't actually specify that a system which has multiple interfaces participating in LLA to each be assigned unique IPs -- presumably because it recommends that hosts only use one interface for LLA, for example see section 2.6.1: A multi-homed host needs to select an outgoing interface whether or not the destination is an IPv4 Link-Local address. Details of that process are beyond the scope of this specification. After selecting an interface, the multi-homed host should send packets involving IPv4 Link-Local addresses as specified in this document, as if the selected interface were the host's only interface. See Section 3 for further discussion of multi-homed hosts. >> The probability that you will have the same LLA appear on two >> distinct subnets >> is a variant of the "birthday paradox"; there's a 10% chance of a >> collision >> with ~120 hosts, and a 50% chance of a collision with 300, >> assuming the code >> copied below is right. > > Not exactly. I think that that computes the probability that a > newly attached host will pick an initial IP address that is already > in use. To apply it to a pair of networks, you need to deal with > how many hosts are on each network and the fact that within each > network, the IPs are already guaranteed to be unique. > > So, given two networks, one with N hosts, the other with M; for the > first host in N, the chance of collision is M / 65024; for the > second it is M / 65023; etc. (Each host in N reduces the available > address space from which the other N-hosts may be chosen; it does > not increase the number of hosts that they must be compared > against.) The total probability is the sum of the probabilities > for each of the N hosts. Hmm, I think you've got a point-- certainly, having two networks starting with hosts guaranteed unique IPs reduces the chances of collisions when they merge, but you might very well be coalescing many disjoint networks rather than just two-- consider bringing up a new wireless basestation which links multiple smaller clouds of wireless clients, for example. Regardless of the actual probability, dealing with IP collisions when using LLAs is a requirement, not something which can be passed off to be solved later. -- -Chuck From owner-freebsd-net@FreeBSD.ORG Fri Aug 25 21:18:58 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 36FD916A4E5 for ; Fri, 25 Aug 2006 21:18:58 +0000 (UTC) (envelope-from patl+freebsd@volant.org) Received: from smtp.volant.org (gate.volant.org [207.111.218.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1EF3E43D53 for ; Fri, 25 Aug 2006 21:18:56 +0000 (GMT) (envelope-from patl+freebsd@volant.org) Received: from adsl-065-081-071-131.sip.gnv.bellsouth.net ([65.81.71.131] helo=[192.168.1.167]) by smtp.volant.org with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34 (FreeBSD)) id 1GGj7j-000DxU-T3; Fri, 25 Aug 2006 14:22:13 -0700 Date: Fri, 25 Aug 2006 17:17:34 -0400 From: Pat Lashley To: Chuck Swiger Message-ID: <2100BBD52C4028EB4DADA0CB@garrett.local> In-Reply-To: <71ABACA2-25E0-4B4F-89EA-3A70A98330E9@mac.com> References: <20060823221835.GA28978@lor.one-eyed-alien.net> <23D2619F6BACE4E728178EE5@garrett.local> <44ED3BD1.3030206@shapeshifter.se> <44EDA9A5.2050108@shapeshifter.se> <44EDBDD0.4050000@shapeshifter.se> <7CC9AC69410B69EBD31122E4@garrett.local> <44EDDB8C.9090504@shapeshifter.se> <0EC404BA0CA363942D250766@garrett.local> <20060824182640.GA37561@lor.one-eyed-alien.net> <22D92E8D-DE18-4883-8E77-5567AF63DFE0@mac.com> <961EF4A5A611779A598DE704@garrett.local> <5D1A78C8-674C-428D-83B6-3CD2F654A69B@mac.com> <17A034A7E9A76AA9FD37FC11@garrett.local> <71ABACA2-25E0-4B4F-89EA-3A70A98330E9@mac.com> X-Mailer: Mulberry/4.0.0 (Mac OS X) MIME-Version: 1.0 X-Scan-Signature: aa36966b5c9d467b38378fdbacafff97597c3bc6 X-Spam-User: nobody X-Spam-Score: -4.3 (----) X-Spam-Score-Int: -42 X-Spam-Report: This mail has matched the spam-filter tests listed below. See http://spamassassin.org/tag/ for details about the specific tests reported. In general, the higher the number of total points, the more likely that it actually is spam. (The 'required' number of points listed below is the arbitrary number above which the message is normally considered spam.) Content analysis details: (-4.3 points total, 5.0 required) 0.1 HTML_MESSAGE BODY: HTML included in message 0.1 HTML_FONTCOLOR_RED BODY: HTML font color is red -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.4 AWL AWL: Auto-whitelist adjustment Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: Zeroconfig and Multicast DNS 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, 25 Aug 2006 21:18:58 -0000 > > Apple's primary consumer base for Zeroconf systems doesn't normally > > have to deal with multi-homed systems; so it probably isn't much of > > a priority for them. > > Um, Pat...? > > All of the laptops Apple sells have ethernet & 802.11 wireless built in and > thus are multihomed from day one; all of the desktop & Mac mini systems being > sold are ethernet & wireless ready, and I gather that many systems are > purchased with the wireless option. Also note that Apple is also shipping > pretty much everything they sell with Firewire, which only Sony seems to do on > the PC side. Yes, I know, there are 4 Macs in my household. (And an equal number of FreeBSD machines.) I've been using the MBP to send these emails. And, for the record, neither our MacMini nor the PowerMac G4 came with WiFi installed. Apple may have made WiFi standard for new systems; but a lot of their old ones are still Ethernet-only. They may all come with both 10/100(/1000)base-T and WiFi now; but few of them actually -use- both interfaces at once; and even fewer on a single local link. So I stand by my claim that their primary customer base doesn't normally deal with multi-homing; especially not in a Zeroconf context. And yes, I do like the standard FireWire; but I don't see how it relates to the discussion at hand unless you want to talk about using it as a network link. Something that is easy enough to do; but that I suspect happens rarely in situations where more than two hosts are involved. > > They also need to maintain a higher level of easy configurability > > by non-technical users. FreeBSD's target user base leans towards > > the more technical and the more server-oriented. > > Absolutely. LLA & mDNS are targetted for ad-hoc networks which are mostly or > entirely unconfigured; FreeBSD's target user base tends to do things like > setup servers with fixed IPs and configure networks via DHCP, setting up DNS > zones, and so forth. But that doesn't mean that we necessarily -want- to have to deal with all of that. > MacOS users have a much greater demand and use for LLA & mDNS than FreeBSD > users do; after all, Apple has userland apps which take advantage of this > functionality now. So do FreeBSD users who install KDE and/or GNOME. Admittedly, not as many, nor as compelling. Yet. > > Yes, as you say, it is relevant if the host is bridging, but not if > > it is treating them as separate subnets. Which requires separate > > LLA negotiations; but I don't see where section 4 requires them to > > have separate IP addresses. (It's probably a good idea; but it > > doesn't seem to be required by section 4.) > > It's not required in section 4; see section 3, particularly 3.4. That only applies if both interfaces are on the same link. > > Multi-homed hosts are covered in section 3. Which is basically a > > discussion of some of the problems that are likely to be > > encountered; without mandating (or forbidding) any particular > > solution. > > > > Section 3.4 does require separate LL Ip addresses IF the interfaces > > are on the same link. But, as they point out, the easiest method of > > avoiding auto-immune response is to run the algorithm separately > > for each interface. In which case no special action need be taken > > to determine whether they are on the same link, or to avoid > > requesting the same address; the normal LLA negotiation will ensure > > that one of them wins and the other picks another address. > > This draft RFC doesn't actually specify that a system which has multiple > interfaces participating in LLA to each be assigned unique IPs -- presumably > because it recommends that hosts only use one interface for LLA, for example > see section 2.6.1: > > A multi-homed host needs to select an outgoing interface whether or > not the destination is an IPv4 Link-Local address. Details of that > process are beyond the scope of this specification. After selecting > an interface, the multi-homed host should send packets involving IPv4 > Link-Local addresses as specified in this document, as if the > selected interface were the host's only interface. See Section 3 for > further discussion of multi-homed hosts. But that same discussion in Section 3 appears to contradict that 'pick one' requirement. I also note that Section 2.6.1 says '...should send packets...', not '...SHOULD send packets...'; which implies that it isn't even a strong recommendation. I believe the intent of section 2.6.1 is to indicate that all of the LLA communications relevant to a given interface needs to go through that interface rather than applying the normal routing rules that were designed for more static and unique IP addresses. > > Not exactly. I think that that computes the probability that a > > newly attached host will pick an initial IP address that is already > > in use. To apply it to a pair of networks, you need to deal with > > how many hosts are on each network and the fact that within each > > network, the IPs are already guaranteed to be unique. > > > > So, given two networks, one with N hosts, the other with M; for the > > first host in N, the chance of collision is M / 65024; for the > > second it is M / 65023; etc. (Each host in N reduces the available > > address space from which the other N-hosts may be chosen; it does > > not increase the number of hosts that they must be compared > > against.) The total probability is the sum of the probabilities > > for each of the N hosts. > > Hmm, I think you've got a point-- certainly, having two networks starting with > hosts guaranteed unique IPs reduces the chances of collisions when they merge, > but you might very well be coalescing many disjoint networks rather than just > two-- consider bringing up a new wireless basestation which links multiple > smaller clouds of wireless clients, for example. But in that case you are more likely to be merging those local links into a single larger one. I'm not saying that situation will never occur; just that I believe it will be much less common. > Regardless of the actual probability, dealing with IP collisions when using > LLAs is a requirement, not something which can be passed off to be solved > later. Actually, I just thought of a simple (but not necessarily pretty) way to do it. The multi-homed host could perform NAT on the incoming packets in the 169.254/16 network, using separate NAT pools on each interface. The applications, and the bulk of the system code would only see the translated addresses, which would be routed to the right interfaces and then translated back to the correct LLA address. You could translate 169.254.x.y into 127.i.x.y, where 'i' identifies the interface; then you wouldn't even need to keep NAT tables. (To maintain RFC compliance with respect to the 127/8 network, you'd need to implement it using (additional) loopback interfaces; but that's a quibble.) And you'd need to ensure that 'i' didn't put you into a range that's already in use by some other RFC or de-facto standard. (So it shouldn't be 0, or 127.) Of course, that only handles the basic address collision issue. Service discovery in that case is still a mess. (The whole concept of handling service discovery across a NAT boundary is making me queasy.) -Pat P.S. No, that proposal is not entirely serious... From owner-freebsd-net@FreeBSD.ORG Fri Aug 25 22:08:14 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 751CA16A4DA for ; Fri, 25 Aug 2006 22:08:14 +0000 (UTC) (envelope-from prvs=julian=38535a252@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3B2A54415A for ; Fri, 25 Aug 2006 22:08:14 +0000 (GMT) (envelope-from prvs=julian=38535a252@elischer.org) Received: from unknown (HELO [192.168.2.6]) ([10.251.60.50]) by a50.ironport.com with ESMTP; 25 Aug 2006 15:08:13 -0700 Message-ID: <44EF74CD.6080500@elischer.org> Date: Fri, 25 Aug 2006 15:08:13 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Elischer References: <44EF6E18.6090905@elischer.org> In-Reply-To: <44EF6E18.6090905@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net Subject: Re: possible patch for implementing split DNS 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, 25 Aug 2006 22:08:14 -0000 Julian Elischer wrote: > I need some processes to look elsewhere for DNS information from where > the rest > of the system looks.. This patch seems to me a simple solution. > We over-ride where the resolver looks for resolv.conf using an > environment variable. > This would allow me to reset this to an application specific config > file that > specifies a different server. > > Anyone got better ways fo doing this? oops patch had a bug.. here's the fixed version (permission checks were screwed up) %diff -u ./lib/libc/net/res_init.c /tmp/res_init.c --- ./lib/libc/net/res_init.c Thu Sep 9 10:42:18 2004 +++ /tmp/res_init.c Fri Aug 25 15:05:59 2006 @@ -154,6 +154,7 @@ int nserv = 0; /* number of nameserver records read from file */ int haveenv = 0; int havesearch = 0; + char *conf_path; #ifdef RESOLVSORT int nsort = 0; char *net; @@ -262,7 +263,10 @@ (line[sizeof(name) - 1] == ' ' || \ line[sizeof(name) - 1] == '\t')) - if ((fp = fopen(_PATH_RESCONF, "r")) != NULL) { + if (issetugid() != 0 || (res_path = getenv("RESOLV_CONF")) == NULL) + res_path = _PATH_RESCONF; + + if ((fp = fopen(res_path, "r")) != NULL) { /* read the config file */ while (fgets(buf, sizeof(buf), fp) != NULL) { /* skip comments */ From owner-freebsd-net@FreeBSD.ORG Fri Aug 25 23:08:51 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5C6D416A529 for ; Fri, 25 Aug 2006 23:08:51 +0000 (UTC) (envelope-from prvs=julian=38535a252@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 66DBA43ECF for ; Fri, 25 Aug 2006 21:39:37 +0000 (GMT) (envelope-from prvs=julian=38535a252@elischer.org) Received: from unknown (HELO [192.168.2.6]) ([10.251.60.50]) by a50.ironport.com with ESMTP; 25 Aug 2006 14:39:36 -0700 Message-ID: <44EF6E18.6090905@elischer.org> Date: Fri, 25 Aug 2006 14:39:36 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: FreeBSD Net Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: possible patch for implementing split DNS 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, 25 Aug 2006 23:08:51 -0000 I need some processes to look elsewhere for DNS information from where the rest of the system looks.. This patch seems to me a simple solution. We over-ride where the resolver looks for resolv.conf using an environment variable. This would allow me to reset this to an application specific config file that specifies a different server. Anyone got better ways fo doing this? %diff -u ./lib/libc/net/res_init.c /tmp/res_init.c --- ./lib/libc/net/res_init.c Thu Sep 9 10:42:18 2004 +++ /tmp/res_init.c Fri Aug 25 14:31:41 2006 @@ -154,6 +154,7 @@ int nserv = 0; /* number of nameserver records read from file */ int haveenv = 0; int havesearch = 0; + char *conf_path; #ifdef RESOLVSORT int nsort = 0; char *net; @@ -262,7 +263,10 @@ (line[sizeof(name) - 1] == ' ' || \ line[sizeof(name) - 1] == '\t')) - if ((fp = fopen(_PATH_RESCONF, "r")) != NULL) { + if (issetugid() == 0 && (res_path = getenv("RESOLV_CONF")) != NULL) + res_path = _PATH_RESCONF; + + if ((fp = fopen(res_path, "r")) != NULL) { /* read the config file */ while (fgets(buf, sizeof(buf), fp) != NULL) { /* skip comments */ From owner-freebsd-net@FreeBSD.ORG Sat Aug 26 00:02:49 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A0A9F16A4E5 for ; Sat, 26 Aug 2006 00:02:49 +0000 (UTC) (envelope-from prvs=julian=386edef67@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 45D0743D46 for ; Sat, 26 Aug 2006 00:02:49 +0000 (GMT) (envelope-from prvs=julian=386edef67@elischer.org) Received: from unknown (HELO [192.168.2.6]) ([10.251.60.50]) by a50.ironport.com with ESMTP; 25 Aug 2006 17:02:48 -0700 Message-ID: <44EF8FA9.3090508@elischer.org> Date: Fri, 25 Aug 2006 17:02:49 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rajkumar S References: <64de5c8b0608250849p2912457cs84c227cc914d1f10@mail.gmail.com> In-Reply-To: <64de5c8b0608250849p2912457cs84c227cc914d1f10@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Netgraph plumbing question 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, 26 Aug 2006 00:02:49 -0000 Rajkumar S wrote: > Hi, > > In the ng_split node is it possible to merge 2 incoming streams into > mixed, while all packets received at mixed goes via out? If merge node > does not support that, is there any other way to get the same result? this is used to separate the streams going in different directions. for example: (fixed fomt needed) _____________ <-----A-------[ ng_split ]<-----A------ ------B------>[ ] ~~~~~~~~~~~~~ | B | v you can also use ng_tee for this sort of thing. e.g. _____________ <-----A&C-----[ ng_tee ]<-----A------ ------B------>[ ]------B------> ~~~~~~~~~~~~~ |^ |^ v| B| ## |C v| in addition arbtrarily complicated switching can be done with the ng_bpf node though it takes more to set it up. there may be other nods that can do what you want too.. check out all the nodes give by: man -k ng_ or it is easy to write your own, starting with /usr/src/sys/netgraph/ng_sample.c > > regards, > > raj > _______________________________________________ > 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 Sat Aug 26 09:22:37 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5B5CD16A500; Sat, 26 Aug 2006 09:22:37 +0000 (UTC) (envelope-from fli+freebsd-net@shapeshifter.se) Received: from mx1.h3q.net (manticore.shapeshifter.se [212.37.5.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id D603843D53; Sat, 26 Aug 2006 09:22:36 +0000 (GMT) (envelope-from fli+freebsd-net@shapeshifter.se) Received: from localhost (localhost [127.0.0.1]) by mx1.h3q.net (Postfix) with ESMTP id 643691A78D; Sat, 26 Aug 2006 11:22:32 +0200 (CEST) Received: from mx1.h3q.net ([127.0.0.1]) by localhost (mx1.h3q.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63187-09; Sat, 26 Aug 2006 11:22:31 +0200 (CEST) Received: from [192.168.1.100] (217-208-33-252-o926.tbon.telia.com [217.208.33.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.h3q.net (Postfix) with ESMTP id DCB211A72A; Sat, 26 Aug 2006 11:22:30 +0200 (CEST) Message-ID: <44F012D2.1090207@shapeshifter.se> Date: Sat, 26 Aug 2006 11:22:26 +0200 From: Fredrik Lindberg User-Agent: Thunderbird 1.5.0.4 (X11/20060727) MIME-Version: 1.0 To: Pat Lashley References: <72BA6AF827AADB0CFEB845DA@2EEC3F7CCB6B8A97580F632A> <44EE9D66.80105@shapeshifter.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at h3q.net Cc: freebsd-net@freebsd.org, Doug Barton Subject: Re: Zeroconfig and Multicast DNS 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, 26 Aug 2006 09:22:37 -0000 Pat Lashley wrote: >> > No, I don't think that there's any good reason to restrict mDNS service >> > discovery to .local; when you're using some other domain on the LAN, >> you >> > still want to easily do the dynamic service advertisement, even if >> the A >> > records are being handled by a traditional unicast DNS server and >> static >> > IP allocation. >> >> Well, this would cause an authority conflict if it's on by default as >> anyone on the local network would be able to announce SD records in >> a domain they do not have authority over. > > The normal use of SD requires the ability of non-privileged users to > announce services on the FQDN of the host upon which they are running. > (Think iTunes playlist sharing.) > >> Do do SD updates to an DNS zone you would need to enable dynamic updates >> on that name server, just as the Service Discovery specifications says. > > What makes you think that there even IS a unicast DNS server for the > (sub)domain in question? I would expect anyone using a real domain (as in using a real TLD, and a name registered at a domain registrar) to have a unicast DNS server. Otherwise they have no "right" to use that name, even if it is only in a local network. >> I don't say that we shouldn't support it, but it should not be on by >> default. And it will actually boil down to what the mdns nss module >> allows. > > I agree that it should not be on by default. But there should be one > simple knob in rc.conf to cause service advertisements to be published > for both .local and the host domain. Any thing more complex would > require editing mdns.conf. > Publishing announcements is one thing, what the nss mdns module allows a host to resolve is what will limit its initial usage. Fredrik Lindberg From owner-freebsd-net@FreeBSD.ORG Sat Aug 26 11:21:43 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9731F16A5DD for ; Sat, 26 Aug 2006 11:21:43 +0000 (UTC) (envelope-from rajkumars@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.183]) by mx1.FreeBSD.org (Postfix) with ESMTP id 28E8643D45 for ; Sat, 26 Aug 2006 11:21:43 +0000 (GMT) (envelope-from rajkumars@gmail.com) Received: by py-out-1112.google.com with SMTP id o67so1515978pye for ; Sat, 26 Aug 2006 04:21:42 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=qbN4H6UflaQnLbunjxz0/DVCVZTBu47EIWOHe497m4XrweyPYAh4UrqxNbL2s2Dj938XE/b+uInHWF9TcEc8s5AkAVCinYOCtg3wo0H7/cxSkRarJuabAzOqWh2g4g0E/aWBIbdA5daoJRS4eyDVI0BaSc5UYwbX0CjBp+4z+NI= Received: by 10.65.185.3 with SMTP id m3mr4871851qbp; Sat, 26 Aug 2006 04:21:42 -0700 (PDT) Received: by 10.65.248.1 with HTTP; Sat, 26 Aug 2006 04:21:42 -0700 (PDT) Message-ID: <64de5c8b0608260421w5a784cek8a3481b7ef4f215c@mail.gmail.com> Date: Sat, 26 Aug 2006 16:51:42 +0530 From: "Rajkumar S" To: "Julian Elischer" , freebsd-net@freebsd.org In-Reply-To: <44EF8FA9.3090508@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <64de5c8b0608250849p2912457cs84c227cc914d1f10@mail.gmail.com> <44EF8FA9.3090508@elischer.org> Cc: Subject: Re: Netgraph plumbing question 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, 26 Aug 2006 11:21:43 -0000 On 8/26/06, Julian Elischer wrote: > in addition arbtrarily complicated switching can be done with the ng_bpf > node though it takes more to set it up. Thanks, I have a question related to the use of ng_bpf, I will post that in a seperate thread. > there may be other nods that can do what you want too.. > check out all the nodes give by: ng_hub is good enough to do a proof of concept, if required I shall try writing a new node. Thanks a lot again for your help. raj From owner-freebsd-net@FreeBSD.ORG Sat Aug 26 13:59:05 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3461816A4E2; Sat, 26 Aug 2006 13:59:05 +0000 (UTC) (envelope-from patl+freebsd@volant.org) Received: from smtp.volant.org (gate.volant.org [207.111.218.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 04290442A4; Sat, 26 Aug 2006 13:58:59 +0000 (GMT) (envelope-from patl+freebsd@volant.org) Received: from ip70-171-56-90.ga.at.cox.net ([70.171.56.90] helo=[172.19.1.101]) by smtp.volant.org with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34 (FreeBSD)) id 1GGyjh-000NCh-0f; Sat, 26 Aug 2006 07:02:22 -0700 Date: Sat, 26 Aug 2006 09:56:23 -0400 From: Pat Lashley To: Fredrik Lindberg Message-ID: <3E29077FA25E6B14361D2C3B@2EEC3F7CCB6B8A97580F632A> X-Mailer: Mulberry/4.0.0 (Mac OS X) MIME-Version: 1.0 X-Scan-Signature: 7df7e02cd58c899f213e00c08c15e862c2970619 X-Spam-User: nobody X-Spam-Score: -3.3 (---) X-Spam-Score-Int: -32 X-Spam-Report: This mail has matched the spam-filter tests listed below. See http://spamassassin.org/tag/ for details about the specific tests reported. In general, the higher the number of total points, the more likely that it actually is spam. (The 'required' number of points listed below is the arbitrary number above which the message is normally considered spam.) Content analysis details: (-3.3 points total, 5.0 required) 2.2 DOMAIN_BODY BODY: Domain registration spam body 0.1 HTML_MESSAGE BODY: HTML included in message 0.3 HTML_FONT_BIG BODY: HTML has a big font 0.1 HTML_FONTCOLOR_RED BODY: HTML font color is red -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] -1.0 AWL AWL: Auto-whitelist adjustment Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, Doug Barton Subject: Re: Zeroconfig and Multicast DNS 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, 26 Aug 2006 13:59:05 -0000 > > What makes you think that there even IS a unicast DNS server for the > > (sub)domain in question? > > I would expect anyone using a real domain (as in using a real TLD, > and a name registered at a domain registrar) to have a unicast DNS > server. But those servers are typically outside the firewall (or in a DMZ). Their purpose is to advertise the publicly visible hosts. The LAN(s) behind the firewall typically use a completely different DNS server. And often one or more subdomains that are not normally exposed to the public. Also, as is pointed out in draft-cheshire-dnsext-dns-sd.txt: Note that the DNS-SD service does NOT have to be provided by the same DNS server hardware that is currently providing an organization's conventional host name lookup service (the service we traditionally think of when we say "DNS"). By delegating the "_tcp" subdomain, all the workload related to DNS-SD can be offloaded to a different machine. This flexibility, to handle DNS-SD on the main DNS server, or not, at the network administrator's discretion, is one of the things that makes DNS-SD so compelling. (I'm not sure why they don't mention the _udp subdomain here.) And from draft-cheshire-dnsext-multicastdns.txt: Multicast DNS Domains are not delegated from their parent domain via use of NS records. There are no NS records anywhere in Multicast DNS Domains. Instead, all Multicast DNS Domains are delegated to the IP addresses 224.0.0.251 and FF02::FB by virtue of the individual organizations producing DNS client software deciding how to handle those names. It would be extremely valuable for the industry if this special handling were ratified and recorded by IANA, since otherwise the special handling provided by each vendor is likely to be inconsistent. The IPv4 name server for a Multicast DNS Domain is 224.0.0.251. The IPv6 name server for a Multicast DNS Domain is FF02::FB. These are multicast addresses; therefore they identify not a single host but a collection of hosts, working in cooperation to maintain some reasonable facsimile of a competently managed DNS zone. Conceptually a Multicast DNS Domain is a single DNS zone, however its server is implemented as a distributed process running on a cluster of loosely cooperating CPUs rather than as a single process running on a single CPU. Given that, in a situation where there is a unicast DNS server(*), the standard nsswitch order should be 'files dns mdns', with the DNS server containing records to delegate .local, .254.169.in-addr.arpa, and ._{tcp,udp}.$(local domain) to the mDNS IP address(es). We may want to add those delegations to our default BIND configuration files. Possibly commented-out with a 'Uncomment these if you want to use mDNS or mDNS-SD on your LAN' comment. (*)Note that here I'm ignoring the situation where the primary DNS server is under some outside administrative control where it is not possible to add those records. Which is a far too common situation for small business owners. > Otherwise they have no "right" to use that name, even if > it is only in a local network. WRONG! Once you register a name, you have the right to use it; you are NOT required to provide ANY publicly available DNS records for it. Of course, if you don't, it will only be useful internally; but there are situations where that's desirable. (You also have the right to not use it at all; in which case you are just preventing anyone else from using it.) > >> I don't say that we shouldn't support it, but it should not be on by > >> default. And it will actually boil down to what the mdns nss module > >> allows. > > > > I agree that it should not be on by default. But there should be one > > simple knob in rc.conf to cause service advertisements to be published > > for both .local and the host domain. Any thing more complex would > > require editing mdns.conf. > > Publishing announcements is one thing, what the nss mdns module allows > a host to resolve is what will limit its initial usage. It should allow clients to resolve -any- service-related records that are available as defined in the protocol. BUT please note that service browsers and clients will normally only -search- in one default domain or in a list of domains provided by {b,db,r,dr,lb}._dns-sd._udp services. And that clients will normally include domain information in the list of choices presented to the user. I agree that there should be a separate knob for whether to to try mDNS for name resolution for names outside the .local domain. And I think that the knob should have at least four states: ".local only", ".local and this host's domain", ".local and .{_tcp,_udp}.*" and "anything". There are inherent security issues in using mDNS at all. But in many cases, particularly the home user with a LAN, LAN parties, etc. the convenience far outweighs the potential hazards. In most cases, I expect zeroconf hosts to be satisfied with residing only in the .local domain; which greatly reduces the ability of a malicious host on the LAN to manipulate DNS responses for external entities. BUT note that in a true zero-configuration setup, the host must use DNS-SD to discover the unicast DNS server that's handling global queries. -Pat From owner-freebsd-net@FreeBSD.ORG Sat Aug 26 15:16:29 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2C06C16A541 for ; Sat, 26 Aug 2006 15:16:29 +0000 (UTC) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (relay0.rambler.ru [81.19.66.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 76BA4447EC for ; Sat, 26 Aug 2006 14:44:08 +0000 (GMT) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (localhost [127.0.0.1]) by relay0.rambler.ru (Postfix) with ESMTP id 5C5C85E59; Sat, 26 Aug 2006 18:44:07 +0400 (MSD) Received: from edoofus.park.rambler.ru (unknown [81.19.65.108]) by relay0.rambler.ru (Postfix) with ESMTP id 3BCEA5E58; Sat, 26 Aug 2006 18:44:07 +0400 (MSD) Received: (from ru@localhost) by edoofus.park.rambler.ru (8.13.6/8.13.6) id k7QEiO5L030529; Sat, 26 Aug 2006 18:44:24 +0400 (MSD) (envelope-from ru) Date: Sat, 26 Aug 2006 18:44:24 +0400 From: Ruslan Ermilov To: Rajkumar S Message-ID: <20060826144424.GC30165@rambler-co.ru> References: <64de5c8b0608250849p2912457cs84c227cc914d1f10@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jq0ap7NbKX2Kqbes" Content-Disposition: inline In-Reply-To: <64de5c8b0608250849p2912457cs84c227cc914d1f10@mail.gmail.com> User-Agent: Mutt/1.5.12-2006-07-14 X-Virus-Scanned: No virus found Cc: freebsd-net@freebsd.org Subject: Re: Netgraph plumbing question 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, 26 Aug 2006 15:16:29 -0000 --jq0ap7NbKX2Kqbes Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 25, 2006 at 09:19:04PM +0530, Rajkumar S wrote: > In the ng_split node is it possible to merge 2 incoming streams into > mixed, while all packets received at mixed goes via out? If merge node > does not support that, is there any other way to get the same result? > No, but it's trivial to set up ng_bpf(4) to do it. Since the default BPF program will be non-matching, "ifNotMatch" action should be used. # ngctl [...] + mkpeer bpf mixed mixed + name mixed bpf + conn bpf: in1 in1 + conn bpf: in2 in2 + conn bpf: out out + msg bpf: setprogram { thisHook=3D"in1" ifNotMatch=3D"mixed" } + msg bpf: setprogram { thisHook=3D"in2" ifNotMatch=3D"mixed" } + msg bpf: setprogram { thisHook=3D"mixed" ifNotMatch=3D"out" } + write in1 33 Rec'd data packet on hook "mixed": 0000: 21 ! + write in2 33 Rec'd data packet on hook "mixed": 0000: 21 ! + write mixed 33 Rec'd data packet on hook "out": 0000: 21 ! Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --jq0ap7NbKX2Kqbes Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFE8F5IqRfpzJluFF4RArghAJwPb2mkdQqQzd+dFLM+q61CX1/gHQCeKMkN zd5mz5mgHsFmYL+gtSrMBNw= =C12K -----END PGP SIGNATURE----- --jq0ap7NbKX2Kqbes-- From owner-freebsd-net@FreeBSD.ORG Sat Aug 26 15:30:11 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 447A116A4E2; Sat, 26 Aug 2006 15:30:11 +0000 (UTC) (envelope-from fli+freebsd-net@shapeshifter.se) Received: from mx1.h3q.net (manticore.shapeshifter.se [212.37.5.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8065343D73; Sat, 26 Aug 2006 15:30:10 +0000 (GMT) (envelope-from fli+freebsd-net@shapeshifter.se) Received: from localhost (localhost [127.0.0.1]) by mx1.h3q.net (Postfix) with ESMTP id 2971E1A78D; Sat, 26 Aug 2006 17:30:08 +0200 (CEST) Received: from mx1.h3q.net ([127.0.0.1]) by localhost (mx1.h3q.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 70445-02; Sat, 26 Aug 2006 17:30:06 +0200 (CEST) Received: from [192.168.1.100] (217-208-33-252-o926.tbon.telia.com [217.208.33.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.h3q.net (Postfix) with ESMTP id 3BDF61A751; Sat, 26 Aug 2006 17:30:06 +0200 (CEST) Message-ID: <44F068FD.1080408@shapeshifter.se> Date: Sat, 26 Aug 2006 17:30:05 +0200 From: Fredrik Lindberg User-Agent: Thunderbird 1.5.0.4 (X11/20060727) MIME-Version: 1.0 To: Pat Lashley References: <3E29077FA25E6B14361D2C3B@2EEC3F7CCB6B8A97580F632A> In-Reply-To: <3E29077FA25E6B14361D2C3B@2EEC3F7CCB6B8A97580F632A> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at h3q.net Cc: freebsd-net@freebsd.org, Doug Barton Subject: Re: Zeroconfig and Multicast DNS 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, 26 Aug 2006 15:30:11 -0000 Pat Lashley wrote: >> >> I would expect anyone using a real domain (as in using a real TLD, >> and a name registered at a domain registrar) to have a unicast DNS >> server. > > But those servers are typically outside the firewall (or in a DMZ). > Their purpose is to advertise the publicly visible hosts. The LAN(s) > behind the firewall typically use a completely different DNS server. And > often one or more subdomains that are not normally exposed to the public. > > Also, as is pointed out in draft-cheshire-dnsext-dns-sd.txt: > > Note that the DNS-SD service does NOT have to be provided by the same > DNS server hardware that is currently providing an organization's > conventional host name lookup service (the service we traditionally > think of when we say "DNS"). By delegating the "_tcp" subdomain, all > the workload related to DNS-SD can be offloaded to a different > machine. This flexibility, to handle DNS-SD on the main DNS server, > or not, at the network administrator's discretion, is one of the > things that makes DNS-SD so compelling. > > (I'm not sure why they don't mention the _udp subdomain here.) Yes, what's your point? SD records are plain DNS records and should be treated for exactly what they are. SD records in a unicast DNS environment would of course obey the rules of unicast DNS (including delegation to other servers). > > And from draft-cheshire-dnsext-multicastdns.txt: > > Multicast DNS Domains are not delegated from their parent domain via > use of NS records. There are no NS records anywhere in Multicast DNS > Domains. Instead, all Multicast DNS Domains are delegated to the IP > addresses 224.0.0.251 and FF02::FB by virtue of the individual > organizations producing DNS client software deciding how to handle > those names. It would be extremely valuable for the industry if this > special handling were ratified and recorded by IANA, since otherwise > the special handling provided by each vendor is likely to be > inconsistent. > > The IPv4 name server for a Multicast DNS Domain is 224.0.0.251. The > IPv6 name server for a Multicast DNS Domain is FF02::FB. These are > multicast addresses; therefore they identify not a single host but a > collection of hosts, working in cooperation to maintain some > reasonable facsimile of a competently managed DNS zone. Conceptually > a Multicast DNS Domain is a single DNS zone, however its server is > implemented as a distributed process running on a cluster of loosely > cooperating CPUs rather than as a single process running on a single > CPU. Yes, I'm aware of this. And SD records in a multicast DNS environment should obey the rules of mDNS. The problem and thing we seem to disagree on is whether SD records outside the .local domain should be allowed to be resolved using mDNS by default. > > Given that, in a situation where there is a unicast DNS server(*), the > standard nsswitch order should be 'files dns mdns', with the DNS server > containing records to delegate .local, .254.169.in-addr.arpa, and > ._{tcp,udp}.$(local domain) to the mDNS IP address(es). > How are you going to delegate between protocols?, while DNS and mDNS share the same PDU format, they should be treated as separate protocols. > We may want to add those delegations to our default BIND configuration > files. Possibly commented-out with a 'Uncomment these if you want to use > mDNS or mDNS-SD on your LAN' comment. > Do you mean a NS record pointing to the mDNS multicast address?, that doesn't seem right and will most likely confuse normal DNS clients and servers. For example the server would not be multicast aware, and if it does get a reply to one of its queries it will originate from a different ip than to which the query was sent. > > >> Otherwise they have no "right" to use that name, even if >> it is only in a local network. > > WRONG! Once you register a name, you have the right to use it; you are > NOT required to provide ANY publicly available DNS records for it. Of > course, if you don't, it will only be useful internally; but there are > situations where that's desirable. (You also have the right to not use > it at all; in which case you are just preventing anyone else from using > it.) I was referring to the use of a domain with a real TLD that you didn't register at a domain registrar (and might belong to somebody else). Of course if you own a domain you can use it as you like. > >> >> I don't say that we shouldn't support it, but it should not be on by >> >> default. And it will actually boil down to what the mdns nss module >> >> allows. >> > >> > I agree that it should not be on by default. But there should be one >> > simple knob in rc.conf to cause service advertisements to be published >> > for both .local and the host domain. Any thing more complex would >> > require editing mdns.conf. >> >> Publishing announcements is one thing, what the nss mdns module allows >> a host to resolve is what will limit its initial usage. > > It should allow clients to resolve -any- service-related records that > are available as defined in the protocol. BUT please note that service > browsers and clients will normally only -search- in one default domain > or in a list of domains provided by {b,db,r,dr,lb}._dns-sd._udp > services. And that clients will normally include domain information in > the list of choices presented to the user. > > I agree that there should be a separate knob for whether to to try mDNS > for name resolution for names outside the .local domain. And I think > that the knob should have at least four states: ".local only", ".local > and this host's domain", ".local and .{_tcp,_udp}.*" and "anything". > > We have been over this already and concluded that the mdns nss module should only allow (in its default state) queries to a few selected domains. SD records are just *plain* (m)dns records and will have to obey the same rules as any other records. _tcp.local. would be allow to be resolved via mDNS while _tcp.example.com would not. However, we *might* ship with a default configuration to the mdns nss module that would add {_tcp,_udp}.* to the set of domains that the nss module would allow to be resolved. A Service Discovery browser application that utilize the mDNS API directly would of course be allowed to do any type of query. But queries going through the more generalized NSS environment should be restricted by default. Fredrik Lindberg From owner-freebsd-net@FreeBSD.ORG Sat Aug 26 17:30:26 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EDCE916A52F; Sat, 26 Aug 2006 17:30:25 +0000 (UTC) (envelope-from patl@volant.org) Received: from smtp.volant.org (gate.volant.org [207.111.218.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F435446A5; Sat, 26 Aug 2006 17:08:23 +0000 (GMT) (envelope-from patl@volant.org) Received: from adsl-065-081-071-131.sip.gnv.bellsouth.net ([65.81.71.131] helo=[172.19.1.101]) by smtp.volant.org with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34 (FreeBSD)) id 1GH1gj-000OvN-Io; Sat, 26 Aug 2006 10:11:46 -0700 Date: Sat, 26 Aug 2006 13:07:02 -0400 From: Pat Lashley To: Fredrik Lindberg Message-ID: In-Reply-To: <44F068FD.1080408@shapeshifter.se> References: <3E29077FA25E6B14361D2C3B@2EEC3F7CCB6B8A97580F632A> <44F068FD.1080408@shapeshifter.se> X-Mailer: Mulberry/4.0.0 (Mac OS X) MIME-Version: 1.0 X-Scan-Signature: cce6216813dd75456e75c7a28f1042d10685cd2f X-Spam-User: nobody X-Spam-Score: -1.6 (-) X-Spam-Score-Int: -15 X-Spam-Report: This mail has matched the spam-filter tests listed below. See http://spamassassin.org/tag/ for details about the specific tests reported. In general, the higher the number of total points, the more likely that it actually is spam. (The 'required' number of points listed below is the arbitrary number above which the message is normally considered spam.) Content analysis details: (-1.6 points total, 5.0 required) 2.2 DOMAIN_BODY BODY: Domain registration spam body 0.1 HTML_MESSAGE BODY: HTML included in message 0.1 HTML_FONTCOLOR_RED BODY: HTML font color is red -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.9 AWL AWL: Auto-whitelist adjustment Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, Doug Barton Subject: Re: Zeroconfig and Multicast DNS 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, 26 Aug 2006 17:30:26 -0000 > >> I would expect anyone using a real domain (as in using a real TLD, > >> and a name registered at a domain registrar) to have a unicast DNS > >> server. > > > > But those servers are typically outside the firewall (or in a DMZ). > > Their purpose is to advertise the publicly visible hosts. The LAN(s) > > behind the firewall typically use a completely different DNS server. And > > often one or more subdomains that are not normally exposed to the public. > > > > Also, as is pointed out in draft-cheshire-dnsext-dns-sd.txt: > > > > Note that the DNS-SD service does NOT have to be provided by the same > > DNS server hardware that is currently providing an organization's > > conventional host name lookup service (the service we traditionally > > think of when we say "DNS"). By delegating the "_tcp" subdomain, all > > the workload related to DNS-SD can be offloaded to a different > > machine. This flexibility, to handle DNS-SD on the main DNS server, > > or not, at the network administrator's discretion, is one of the > > things that makes DNS-SD so compelling. > > > > (I'm not sure why they don't mention the _udp subdomain here.) > > Yes, what's your point? SD records are plain DNS records and should > be treated for exactly what they are. SD records in a unicast DNS > environment would of course obey the rules of unicast DNS (including > delegation to other servers). My point is that it doesn't really matter whether anyone using a real domain already has a unicast DNS server. That does not provide any impediment at all if they wish to use mDNS for service discovery. Or even for link-local host lookups in their domain. (By either delegating their domain if the request was from within the LAN or creating a sub-domain that is always delegated.) > > And from draft-cheshire-dnsext-multicastdns.txt: > > > > Multicast DNS Domains are not delegated from their parent domain via > > use of NS records. There are no NS records anywhere in Multicast DNS > > Domains. Instead, all Multicast DNS Domains are delegated to the IP > > addresses 224.0.0.251 and FF02::FB by virtue of the individual > > organizations producing DNS client software deciding how to handle > > those names. It would be extremely valuable for the industry if this > > special handling were ratified and recorded by IANA, since otherwise > > the special handling provided by each vendor is likely to be > > inconsistent. > > > > The IPv4 name server for a Multicast DNS Domain is 224.0.0.251. The > > IPv6 name server for a Multicast DNS Domain is FF02::FB. These are > > multicast addresses; therefore they identify not a single host but a > > collection of hosts, working in cooperation to maintain some > > reasonable facsimile of a competently managed DNS zone. Conceptually > > a Multicast DNS Domain is a single DNS zone, however its server is > > implemented as a distributed process running on a cluster of loosely > > cooperating CPUs rather than as a single process running on a single > > CPU. > > Yes, I'm aware of this. And SD records in a multicast DNS environment > should obey the rules of mDNS. > The problem and thing we seem to disagree on is whether SD records > outside the .local domain should be allowed to be resolved using > mDNS by default. I have no problem with having that off by default; as long as it can be turned on through the use of a single simple knob in rc.conf. (And that all of the rc.conf mDNS and LLA knobs be setable from the sysinstall menus.) Just don't make it so that mDNS -only- works for .local and the link local in-addr.arpa domains. > > Given that, in a situation where there is a unicast DNS server(*), the > > standard nsswitch order should be 'files dns mdns', with the DNS server > > containing records to delegate .local, .254.169.in-addr.arpa, and > > ._{tcp,udp}.$(local domain) to the mDNS IP address(es). > > > > How are you going to delegate between protocols?, while DNS and > mDNS share the same PDU format, they should be treated as separate > protocols. The draft RFC indicates that those (sub)domains should be delegated. It does not prohibit delegation of other (sub)domains. > > We may want to add those delegations to our default BIND configuration > > files. Possibly commented-out with a 'Uncomment these if you want to use > > mDNS or mDNS-SD on your LAN' comment. > > > > Do you mean a NS record pointing to the mDNS multicast address?, that > doesn't seem right and will most likely confuse normal DNS clients > and servers. According to section 12, current implementations delegate .local, .254.169.in-addr.arpa, and FF02::/16 via special-case code. If you're going to do that, you may as well recognize explicit NS delegations to 224.0.0.251 and FF02::FB > For example the server would not be multicast aware, and if it does > get a reply to one of its queries it will originate from a different > ip than to which the query was sent. That might be an argument against mixing them for host lookup; but for service discovery, this is really only going to come up for clients that are using DNS-SD; and there's absolutely no reason why the dns-sd library shouldn't handle it properly. I'm not familiar with the internals of the nsswitch and resolver code to propose any particular solution; but there's no reason why it can't be made to work cleanly. At worst case, you'd need a single nss module that could handle both DNS and mDNS. > >> Otherwise they have no "right" to use that name, even if > >> it is only in a local network. > > > > WRONG! Once you register a name, you have the right to use it; you are > > NOT required to provide ANY publicly available DNS records for it. Of > > course, if you don't, it will only be useful internally; but there are > > situations where that's desirable. (You also have the right to not use > > it at all; in which case you are just preventing anyone else from using > > it.) > > I was referring to the use of a domain with a real TLD that you didn't > register at a domain registrar (and might belong to somebody else). > Of course if you own a domain you can use it as you like. You might be able to get by with using 'example.com'; but I wouldn't advise trying it. In any case; I don't think that we need to worry about people trying to use unregistered domains. My point is that just because a domain is registered doesn't mean that there are any unicast DNS servers providing authoritative records for it. (Admittedly, it's probably a very good idea to at least have one; even if it only contains the SOA.) People will have good reasons to want to use a domain other than .local with mDNS; and to use both that domain and .local at the same time. And quite possibly to use multiple domains in additional to .local. Let's not get in their way. > We have been over this already and concluded that the mdns nss module > should only allow (in its default state) queries to a few selected > domains. SD records are just *plain* (m)dns records and will have to > obey the same rules as any other records. _tcp.local. would be allow > to be resolved via mDNS while _tcp.example.com would not. > However, we *might* ship with a default configuration to the mdns nss > module that would add {_tcp,_udp}.* to the set of domains that > the nss module would allow to be resolved. I think we need a third state where it only adds {_tcp,_udp}.$(domain) to the list. > A Service Discovery browser application that utilize the mDNS API > directly would of course be allowed to do any type of query. > But queries going through the more generalized NSS environment should > be restricted by default. Hmmm. Yes, I think that's a valid distinction. The nss_dns module and the dns-sd library need not have the same set of default restrictions. Applications using the nsswitch only are unlikely to be using DNS-SD at all; and cannot be expected to be able to cope with delegation to a multicast address. Those using libdns_sd are almost certain to be mDNS-aware; and the library can handle the choice of mDNS -vs- unicast for particular queries (and the potential recursion needed to resolve them.) But that means that some of the configuration choices will need to be available to the dns-sd library. (E.g., Whether to use mDNS only for .local, or also for _{tcp,udp}.DOMAIN, _{tcp,udp}.*, or for everything.) -Pat From owner-freebsd-net@FreeBSD.ORG Sat Aug 26 17:45:23 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B65AC16A4DF; Sat, 26 Aug 2006 17:45:23 +0000 (UTC) (envelope-from fli+freebsd-net@shapeshifter.se) Received: from mx1.h3q.net (manticore.shapeshifter.se [212.37.5.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2890643D55; Sat, 26 Aug 2006 17:45:22 +0000 (GMT) (envelope-from fli+freebsd-net@shapeshifter.se) Received: from localhost (localhost [127.0.0.1]) by mx1.h3q.net (Postfix) with ESMTP id A985A1A78D; Sat, 26 Aug 2006 19:45:20 +0200 (CEST) Received: from mx1.h3q.net ([127.0.0.1]) by localhost (mx1.h3q.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 70445-08; Sat, 26 Aug 2006 19:45:19 +0200 (CEST) Received: from [192.168.1.100] (217-208-33-252-o926.tbon.telia.com [217.208.33.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.h3q.net (Postfix) with ESMTP id DDA6D1A751; Sat, 26 Aug 2006 19:45:18 +0200 (CEST) Message-ID: <44F088AD.8000408@shapeshifter.se> Date: Sat, 26 Aug 2006 19:45:17 +0200 From: Fredrik Lindberg User-Agent: Thunderbird 1.5.0.4 (X11/20060727) MIME-Version: 1.0 To: Pat Lashley References: <3E29077FA25E6B14361D2C3B@2EEC3F7CCB6B8A97580F632A> <44F068FD.1080408@shapeshifter.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at h3q.net Cc: freebsd-net@freebsd.org, Doug Barton Subject: Re: Zeroconfig and Multicast DNS 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, 26 Aug 2006 17:45:23 -0000 Pat Lashley wrote: >> >> Yes, I'm aware of this. And SD records in a multicast DNS environment >> should obey the rules of mDNS. >> The problem and thing we seem to disagree on is whether SD records >> outside the .local domain should be allowed to be resolved using >> mDNS by default. > > I have no problem with having that off by default; as long as it can be > turned on through the use of a single simple knob in rc.conf. (And that > all of the rc.conf mDNS and LLA knobs be setable from the sysinstall > menus.) > > Just don't make it so that mDNS -only- works for .local and the link > local in-addr.arpa domains. Of course not, that has never been my intention. > >> > We may want to add those delegations to our default BIND configuration >> > files. Possibly commented-out with a 'Uncomment these if you want to >> use >> > mDNS or mDNS-SD on your LAN' comment. >> > >> >> Do you mean a NS record pointing to the mDNS multicast address?, that >> doesn't seem right and will most likely confuse normal DNS clients >> and servers. > > According to section 12, current implementations delegate .local, > .254.169.in-addr.arpa, and FF02::/16 via special-case code. If you're > going to do that, you may as well recognize explicit NS delegations to > 224.0.0.251 and FF02::FB > >> For example the server would not be multicast aware, and if it does >> get a reply to one of its queries it will originate from a different >> ip than to which the query was sent. > > That might be an argument against mixing them for host lookup; but for > service discovery, this is really only going to come up for clients that > are using DNS-SD; and there's absolutely no reason why the dns-sd > library shouldn't handle it properly. Ok, this would work for a multicast-aware service discovery browser that would understand to switch to mDNS when it receives a NS record pointing to 224.0.0.251/FF02::FB. I suppose we could ship an example configuration for this. > >> We have been over this already and concluded that the mdns nss module >> should only allow (in its default state) queries to a few selected >> domains. SD records are just *plain* (m)dns records and will have to >> obey the same rules as any other records. _tcp.local. would be allow >> to be resolved via mDNS while _tcp.example.com would not. >> However, we *might* ship with a default configuration to the mdns nss >> module that would add {_tcp,_udp}.* to the set of domains that >> the nss module would allow to be resolved. > > I think we need a third state where it only adds {_tcp,_udp}.$(domain) > to the list. > >> A Service Discovery browser application that utilize the mDNS API >> directly would of course be allowed to do any type of query. >> But queries going through the more generalized NSS environment should >> be restricted by default. > > Hmmm. Yes, I think that's a valid distinction. The nss_dns module and > the dns-sd library need not have the same set of default restrictions. > Applications using the nsswitch only are unlikely to be using DNS-SD at > all; and cannot be expected to be able to cope with delegation to a > multicast address. Those using libdns_sd are almost certain to be > mDNS-aware; and the library can handle the choice of mDNS -vs- unicast > for particular queries (and the potential recursion needed to resolve > them.) > > But that means that some of the configuration choices will need to be > available to the dns-sd library. (E.g., Whether to use mDNS only for > .local, or also for _{tcp,udp}.DOMAIN, _{tcp,udp}.*, or for everything.) > To clarify my statements a bit. The *only* place that should restrict which domains that are resolvable is the mDNS NSS module, neither the mDNS client API nor a DNS-SD library should impose any form of restrictions on which types of domains to be resolvable. Clients of these APIs should cope with potential hazards (just as the mdns nss module is a client of the mdns api, and quite sensitive to malicious behavior as it handles gethostbyname etc). Fredrik Lindberg