From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1ZOncl-0005Lr-7T for mharc-grub-devel@gnu.org; Mon, 10 Aug 2015 10:00:23 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41029) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZOnci-0005Lb-5O for grub-devel@gnu.org; Mon, 10 Aug 2015 10:00:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZOncd-000702-GG for grub-devel@gnu.org; Mon, 10 Aug 2015 10:00:20 -0400 Received: from mx0a-00082601.pphosted.com ([67.231.145.42]:40727) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZOncd-0006y9-4s for grub-devel@gnu.org; Mon, 10 Aug 2015 10:00:15 -0400 Received: from pps.filterd (m0044010 [127.0.0.1]) by mx0a-00082601.pphosted.com (8.14.5/8.14.5) with SMTP id t7ADxemC024768; Mon, 10 Aug 2015 07:00:12 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fb.com; h=message-id : date : from : mime-version : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=facebook; bh=XTWHJEOof3BKg8ZH/88hZgBB/mcWat4osYvN9JVJ5qY=; b=LZ+z4OkIl1TvjweR9RZRQ2dptj2Knc35h6dmtEYvD5gKLQztmju1Y44qZHtqnFdiCtkd sNu5pOxyjCeXi687IxQ+3yVYL/rolO6bFzQ+COq9VQtOPw2IwAqy+/LSI0SxF+lKrD/5 PGqo7Q30h3Kl0TSGPY6tWtdkpi7E1hfKsv4= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 1w6ne10txj-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 10 Aug 2015 07:00:12 -0700 Received: from localhost.localdomain (192.168.52.123) by mail.thefacebook.com (192.168.16.19) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 10 Aug 2015 07:00:11 -0700 Message-ID: <55C8AE69.8000201@fb.com> Date: Mon, 10 Aug 2015 10:00:09 -0400 From: Josef Bacik User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Andrei Borzenkov Subject: Re: [PATCH 3/3] net: fix ipv6 routing References: <1438799799-32097-1-git-send-email-jbacik@fb.com> <1438799799-32097-3-git-send-email-jbacik@fb.com> <20150809175828.73d61027@opensuse.site> In-Reply-To: <20150809175828.73d61027@opensuse.site> Content-Type: text/plain; charset="utf-8"; format=flowed X-Originating-IP: [192.168.52.123] X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-08-10_02:2015-08-10, 2015-08-10, 1970-01-01 signatures=0 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mx0a-00082601.pphosted.com id t7ADxemC024768 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x X-Received-From: 67.231.145.42 Cc: grub-devel@gnu.org, mchang@suse.com X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 14:00:21 -0000 On 08/09/2015 10:58 AM, Andrei Borzenkov wrote: > =D0=92 Wed, 5 Aug 2015 14:36:39 -0400 > Josef Bacik =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > >> Currently we cannot talk to ipv6 addresses outside of our local link a= rea >> because we don't setup our routes properly nor do we talk to the route= r >> properly. Currently net_ipv6_autoconf adds routes for the local link = prefix and >> ties it to the global link device. This isn't helpful at all, we comp= letely >> drop the router part of the router advertisement. So instead create a= "default >> route" flag in routes and create a new route with the local link prefi= x and the >> router source address. >> > > Note that RA does not always mean default route. You need to check > router lifetime to decide whether to use it as default route. I've been reading the spec a lot recently and I couldn't figure out a=20 way to differentiate between a default route and just another route.=20 From my reading if we get multipe RA's we're supposed to just round=20 robin through them until we get the one that works, obviously taking=20 into account when the router lifetime expires and such. We don't take=20 into account the lifetime at all except to see if it is set to 0,=20 otherwise we never expire anything. We should probably build this out=20 in the future, but for now just picking whichever router comes first as=20 the default route will work most of the time. > >> The second part of this problem is that the routing code thinks in ipv= 4 terms, >> so it expects to find a route to the address we're looking for in our = routing >> table. If we find a gateway then we just look for which interface mat= ches the >> network for the gateway. This doesn't work for ipv6 since the router = gives us >> its local link address, so the gateway will find the local link interf= ace, >> instead of the global interface. So to deal with this do a few things >> > > I am afraid it cannot be solved on routing table level. We need to bite > the bullet and add notion of interface zone and associate each link > local IPv6 address with interface it comes from (or sent to). This > automatically solves also the problem in your other patch as well as > this one by eliminating need to (attempt to) route link local in the > first place - it is simply sent to interface it is associated with. > > It also means we probably need to support IPv6%scope notation for > addresses. I'll try and work something out that is better than this patch. > >> 1) Create a new "default route" flag for any router advertisements we = get when >> doing the ipv6 autoconf stuff. Then we create a normal gateway route = with the >> default route flag set. >> >> 2) When looking for routes keep track of any default routes we find, a= nd if we >> don't find an exact route that matches we use the default route, which= will set >> the gateway to the router, and then we will find the local link interf= ace that >> matches this router. >> >> 3) Translate the local link interface to the global link interface. W= e build >> the ip packets based on the address on the interface, and this needs t= o have the >> global address, not the local one. So loop through our interfaces unt= il we find >> a global address with the same hwaddress as the local link interface a= nd use >> that instead. This way we get the right addresses on our IP packets. >> > > If I read RFC6724 correctly, we actually must prefer link-local > source address when speaking with link-local destination. Right if we're talking to a link-local destination, but when talking to=20 a global link destination the format is src-ip: global address for the interface dst-ip: global address for destination src-mac: our mac dst-mac: the mac of the default route Which is why I did that weird translation. > >> With this patch I can now do net_ipv6_autoconf and immediately talk to= ipv6 >> addresses outside of my local network. Thanks, >> >> Signed-off-by: Josef Bacik >> --- >> grub-core/net/bootp.c | 2 +- >> grub-core/net/drivers/ieee1275/ofnet.c | 2 +- >> grub-core/net/icmp6.c | 50 ++++++++++------------ >> grub-core/net/net.c | 76 +++++++++++++++++++++---= ---------- >> include/grub/net.h | 28 ++++++++++++- >> 5 files changed, 99 insertions(+), 59 deletions(-) >> > ... >> diff --git a/grub-core/net/icmp6.c b/grub-core/net/icmp6.c >> index 7953e68..fad04a9 100644 >> --- a/grub-core/net/icmp6.c >> +++ b/grub-core/net/icmp6.c >> @@ -373,7 +373,10 @@ grub_net_recv_icmp6_packet (struct grub_net_buff = *nb, >> if (ohdr->type =3D=3D OPTION_PREFIX && ohdr->len =3D=3D 4) >> { >> struct prefix_option *opt =3D (struct prefix_option *) ptr; >> + struct grub_net_route *route; >> struct grub_net_slaac_mac_list *slaac; >> + >> + grub_net_network_level_netaddress_t netaddr; >> if (!(opt->flags & FLAG_SLAAC) >> || (grub_be_to_cpu64 (opt->prefix[0]) >> 48) =3D=3D 0xfe80 >> || (grub_be_to_cpu32 (opt->preferred_lifetime) >> @@ -391,18 +394,12 @@ grub_net_recv_icmp6_packet (struct grub_net_buff= *nb, >> for (slaac =3D card->slaac_list; slaac; slaac =3D slaac->next) >> { >> grub_net_network_level_address_t addr; >> - grub_net_network_level_netaddress_t netaddr; >> - >> if (slaac->address.type >> !=3D GRUB_NET_LINK_LEVEL_PROTOCOL_ETHERNET) >> continue; >> addr.type =3D GRUB_NET_NETWORK_LEVEL_PROTOCOL_IPV6; >> addr.ipv6[0] =3D opt->prefix[0]; >> addr.ipv6[1] =3D grub_net_ipv6_get_id (&slaac->address); >> - netaddr.type =3D GRUB_NET_NETWORK_LEVEL_PROTOCOL_IPV6; >> - netaddr.ipv6.base[0] =3D opt->prefix[0]; >> - netaddr.ipv6.base[1] =3D 0; >> - netaddr.ipv6.masksize =3D 64; >> >> FOR_NET_NETWORK_LEVEL_INTERFACES (inf) >> { >> @@ -410,29 +407,28 @@ grub_net_recv_icmp6_packet (struct grub_net_buff= *nb, >> && grub_net_addr_cmp (&inf->address, &addr) =3D=3D 0) >> break; >> } >> - /* Update lease time if needed here once we have >> - lease times. */ >> - if (inf) >> - continue; >> + if (!inf) >> + slaac->slaac_counter++; >> + } >> >> - grub_dprintf ("net", "creating slaac\n"); >> + netaddr.type =3D GRUB_NET_NETWORK_LEVEL_PROTOCOL_IPV6; >> + netaddr.ipv6.base[0] =3D opt->prefix[0]; >> + netaddr.ipv6.base[1] =3D 0; >> + netaddr.ipv6.masksize =3D 64; >> >> - { >> - char *name; >> - name =3D grub_xasprintf ("%s:%d", >> - slaac->name, slaac->slaac_counter++); >> - if (!name) >> - { >> - grub_errno =3D GRUB_ERR_NONE; >> - continue; >> - } >> - inf =3D grub_net_add_addr (name, >> - card, &addr, >> - &slaac->address, 0); >> - grub_net_add_route (name, netaddr, inf); >> - grub_free (name); >> - } >> - } > > This kills SLAAC. Where global addresses now come from? You probably > get them from DHCPv6 but it does not mean we should drop SLAAC. Eesh I just ripped that out didn't I? Sorry about that, I'll rework=20 this again. I think I'll do like you said above, just kind of create an=20 interface with different scopes and that way if you use both slaac and=20 dhcp and get the same address we don't end up with two different=20 interfaces. And then I'll come up with something to tie the routers to=20 the interfaces and rework the route stuff so it is a bit cleaner. This=20 will probably be towards the end of the week, I've found some weird=20 timeout problem in the TCP stack I'm trying to track down, once I've=20 figured that out I'll rework this patch. Thanks, Josef