From owner-freebsd-net@FreeBSD.ORG Wed Feb 20 10:57:04 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0C22D98C for ; Wed, 20 Feb 2013 10:57:04 +0000 (UTC) (envelope-from bored_to_death85@yahoo.com) Received: from nm29-vm0.bullet.mail.bf1.yahoo.com (nm29-vm0.bullet.mail.bf1.yahoo.com [98.139.213.166]) by mx1.freebsd.org (Postfix) with ESMTP id 7DDE96B2 for ; Wed, 20 Feb 2013 10:57:03 +0000 (UTC) Received: from [98.139.215.140] by nm29.bullet.mail.bf1.yahoo.com with NNFMP; 20 Feb 2013 10:56:55 -0000 Received: from [98.139.212.209] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 20 Feb 2013 10:56:55 -0000 Received: from [127.0.0.1] by omp1018.mail.bf1.yahoo.com with NNFMP; 20 Feb 2013 10:56:55 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 906578.49968.bm@omp1018.mail.bf1.yahoo.com Received: (qmail 75409 invoked by uid 60001); 20 Feb 2013 10:56:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1361357815; bh=yZVlJoxIfyDQPFZhcUGbHjuml5jh/b55+yxoeWD8h+U=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=2MBBd9ogY+tbIqYm4x8k1Xs4I02Yo/F+wM1FqLamAN+Fjti4QGG0sA1V9qTOZTeYB2opJvJozcyEGq+Lx1vo6zlu09dkv4LtO+jqswNWvSw0A12mW3mlZd3LYURTu4YP+8nhBfwiepNHWs8CLhE8fiLjpQu+0eaI8AtlgbUCV3w= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=GBMRxWo56PuWJ2wedhgKyX5Ge1E7PYrRnBS8GPeXn6DBxamf6autoLo7ak7eTIS+wdLQSQUuI6MnoPVYiX/efV1383rsI98fs+BGXoBLqkHE2cMK0mS1d4lH3+KxL3eVANwUB/w1TaND/i2iVpwLQR48wYrenrdhxQ0sD9rhszY=; X-YMail-OSG: j6csv8QVM1kWNcZz2Ka2k_Q6fOk8hU0ysrHo0hWMYVnO319 NSTiG9J8_ny4g0bKoUmjWwqdxr1SYj8xO.fpEQfEAdsiGUtY1TeCJzEYHXht DuvzwuqAwkQJzSzQQ4r.GpSzZorjb0HW5FGzCc3w8H77Q4oSKyFxSDDZ1nv_ lErIYi8x2b6o07KAWU_zsmRqHBRLR2ibBRtHfNFubjbce7.XRfeMZtgV6T9s 0M.ypOuSharY3lDuQcFPU7nKIm1uTCfB4BSB2T9VxWrb1hQcT3Dr58rbKoKI _iSxpdRqZlygUVv4GUUANoRojLEXyFhzg5wrW_etqW8osPX6U1SpdIg.LaEB dsyy0uDG9R39dqh9THAZu1ELHYnwCy9JldVcPxgoL4Etsp.8nE7WAv0DdQie aiu.PW5JWdi1GFRowd05oJm16hYJ8aMHg6qkBqZ0uA23nXTVRg1_3pOa_4yF GzId8olck_zrngP.8ZH9Pwic7PDUiMXo2ZxXZtJ.._jGZ_ICokegKWmUzw15 oBYdf7wWNoRbagJa9ZUXSkhJT_NLDmjPMVLHD.VfhiRhsMuww21fRYoZtI0H 6Eb_OqVtUJhyx0udxcJb_H_RHLLyNx_i60vLOhQdaAZfu.UpR4ezhlI7Wy8f NUhLfa8kkLKxJLgVj1EU- Received: from [94.183.246.198] by web165005.mail.bf1.yahoo.com via HTTP; Wed, 20 Feb 2013 02:56:55 PST X-Rocket-MIMEInfo: 001.001, aGksCgpJIGhhdmUgMiBGcmVlQlNEOC4yIHN5c3RlbXMuIEkgaGF2ZSBhIHBvaW50LXRvLXBvaW50IGludGVyZmFjZSAobXlpZjApIG9uIGVhY2ggc2lkZSBjb25uZWN0ZWQgdG9nZXRoZXIsIGJ1dCBvbiBlYWNoIHNpZGUgSSBkb24ndCBrbm93IElQIGFkZHJlc3Mgb2YgdGhlIG90aGVyIHNpZGUuIHRvIG1ha2UgdGhlIGNvbm5lY3Rpb24gd29yaywgT24gZWFjaCBzaWRlIEkgc2V0IElQIGFkZHJlc3MgKDIuMi4yLjMyLzI0IGFuZCAyLjIuMi4zMy8yNCkgYW5kIGFkZGVkIGEgcm91dGUgd2hpY2ggc2VuZHMgYWwBMAEBAQE- X-Mailer: YahooMailWebService/0.8.134.513 Message-ID: <1361357815.70014.YahooMailNeo@web165005.mail.bf1.yahoo.com> Date: Wed, 20 Feb 2013 02:56:55 -0800 (PST) From: "M. V." Subject: point-to-point network with unknown peer ip address 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.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: "M. V." List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 10:57:04 -0000 hi,=0A=0AI have 2 FreeBSD8.2 systems. I have a point-to-point interface (my= if0) on each side connected together, but on each side I don't know IP addr= ess of the other side. to make the connection work, On each side I set IP a= ddress (2.2.2.32/24 and 2.2.2.33/24) and added a route which sends all traf= fic to the network to interface:=0A#route add 2.2.2.0/24 -interface myif0= =0A=0A#ifconfig myif0=0Amyif0: flags=3D89d1 metric 0 mtu 1500=0A=0A=0Anow my routing table loo= ks like this:=0A=0A#netstat -r=0A=0ADestination=A0Gateway=A0Flags=A0 Refs= =A0 Use=A0 Netif Expire=0A...=0A2.2.2.0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 myif0= =A0=A0=A0 =A0 US=A0 =A0 =A00=A0=A0=A0=A0=A0=A0 145=A0=A0=A0 myif0=0A=0A2.2.= 2.32=A0=A0=A0=A0=A0=A0=A0=A0 link#9=A0 =A0=A0UH=A0=A0=A0=A0 0=A0=A0=A0=A0= =A0=A0 0=A0=A0=A0=A0=A0=A0=A0 lo0=0A...=0A=0Anow, from one side if I ping t= he other side (say 2.2.2.33/24) everything seems ok. but if I ping any othe= r IP in the network (say 2.2.2.100/24) the other endpoint sends back packet= + an ICMP REDIRECT packet. but sender doesn't care about the received ICMP= -REDIRECT and resends packet to interface. this causes a loop and each pack= et is being sent back and forth till its TTL expires.=0A=0Amy sysctl output= :=0A...=0A=0Anet.inet.ip.redirect: 1=0Anet.inet.icmp.drop_redirect: 0=0A...= =0A=0A=0Anow I wanted to ask:=0A- is there any other way to do this? how ca= n I manipulate routes to have a working point-to-point interface with an un= known peer ip address?=A0=0A- if not, shouldn't FreeBSD handle received ICM= P-REDIRECT and stop sending packet to interface after that? how can I make = this happen?=0A=0A=0A=0Athank you.=0A From owner-freebsd-net@FreeBSD.ORG Wed Feb 20 15:16:27 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 76CD6DEF for ; Wed, 20 Feb 2013 15:16:27 +0000 (UTC) (envelope-from annonymouse@gmail.com) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by mx1.freebsd.org (Postfix) with ESMTP id 00AD0A56 for ; Wed, 20 Feb 2013 15:16:26 +0000 (UTC) Received: by mail-we0-f173.google.com with SMTP id r5so6662712wey.32 for ; Wed, 20 Feb 2013 07:16:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=aBgslAgjzMHtluydoKvhMse8KprF1vM1JE+JXu0Gnf4=; b=tM66UArjPPzBeDy3tF7fUIZGtQsXeF/1mmyaOnNmeOYfzgfwUQ+J6MNNgJzj52FoHY rAbPrfi4L9gtrnFotwicmh1kpct2lE8F/aRijEQXy/y4g3ZAc8GWudtgHmjCn3Ihb8v2 r7+A6/bFg9gjkiAXm9upDFeKnWpwkl3joUcuxyk19jl0hu866zknY8k4bctgxp2XsAKI TC3z8M5jvkIWTehu9A4/wSFUDbg+F/Qg0cmdt+Ob/pDD+sw9tMzXqRDN0CBhzyLRp+N6 C0XfhAfW/oskIOetLNaBlkkRyLJeeKJqTgVfR+a8VsxrQ3cPRzb68B2nmEwP29xegXrK pv1g== MIME-Version: 1.0 X-Received: by 10.180.88.168 with SMTP id bh8mr18880193wib.15.1361373377380; Wed, 20 Feb 2013 07:16:17 -0800 (PST) Sender: annonymouse@gmail.com Received: by 10.217.50.67 with HTTP; Wed, 20 Feb 2013 07:16:17 -0800 (PST) In-Reply-To: References: Date: Wed, 20 Feb 2013 15:16:17 +0000 X-Google-Sender-Auth: -bnWrEbMtsHPhPgcpvIIWbUmCWU Message-ID: Subject: Re: Wallclock vs monotonic time in v6 expiry times? From: Alex Yong To: Chuck Swiger Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Feb 2013 15:16:27 -0000 Thanks Chuck for the quick response, On 19 February 2013 18:51, Chuck Swiger wrote: > > Sequence #s, retry timers, etc do better if based off of wall clock time > than if based off of uptime because realtime persists in moving forward but > uptime gets reset if the host crashes/reboots. > > RFC-793 discusses "Quiet Time" concept for TCP, but it applies elsewhere. > > I take your point that it doesn't hurt to use wall clock time always assuming sensible clock stability on your system, as with Quiet Time optimizations and DHCP leases (to pick two examples) anything else wouldn't make sense. However is there any specific reason in the case of v6 prefixes and default routers to do this? As as far as I can tell the kernel does not store these expiry times in non-volatile storage, and neither does rtsold. I don't think it matters if it's monotonic time or not here, as long as you do the appropriate conversion when passing these values up to userland. If you wanted to persist prefixes/default routers across a crash/boot you could do all of this in userland with a modified rtsold or similar, much like with DHCP leases. Or am I missing something? AlexY