On Mon, 09 Mar 2015 09:50:59 +0100 Wilco Baan Hofman <wi...@baanhofman.nl> wrote:
> On 09/03/15 07:42, Timo Teras wrote: > > On Sun, 08 Mar 2015 01:04:16 +0100 > > Wilco Baan Hofman <wi...@baanhofman.nl> wrote: > > > >>> Patch 0001 can be applied easily. > >>> > >>> In Patch 0002 there are likely a few problems. > >>> 1. lladdr.sll_addr can only contain half an IPv6 address (8 > >>> bytes). There is no way to direct a message to an endpoint that I > >>> could find. > >> This is still an issue, patching the kernel and replacing the > >> sll_addr with a 16-byte buffer (as well as in /usr/include/linux), > >> this works.. but this is broken. > > Yes, that's one of the nasty things. Changing the ssl_addr size > > affects ABI, and I'm not sure how well that will work out. Though > > ssl_addr is the last entry of the structure so it might be doable. > > Or perhaps introduce sockaddr_ll_storage or similar for this > > purpose. You might want to start discussion of this problem on > > netdev mailing list. > I did, though no replies yet, aside from "Oops, we need to fix the > kernel memleak first" and "We can't break the ABI" (agreed). Given > that the sll_addr is the last entry in the struct, it only breaks > when a client uses newer headers on an older kernel. But that will > break anyway unless some check is introduced there.. awaiting netdev > replies :-) My experience too. They often say why something does not work, but does not give suggestion. I've learned that best way to provoke / get feedback is to send a patch. > >> However, the kernel seems to have another issue: > >> > >> # ip -6 neigh list > >> fe80::1 dev gre1 lladdr > >> fc:00:00:00:00:00:00:00:00:00:00:00:00:00:00:01 REACHABLE > >> fe80::3 dev gre1 lladdr > >> fc:00:00:00:00:00:00:00:00:00:00:00:00:00:00:03 REACHABLE > >> > >> # ping6 fe80::3%gre1 > >> PING fe80::3%gre1(fe80::3) 56 data bytes > >> .... > >> > >> No packets leaving the interface, error count incrementing. > >> > >>> 2. It assumes that ARPHDR_IP6GRE = IPv6 address types, while in > >>> reality, IPv4 and IPv6 can be completely mixed, this must be fixed > >>> before applying obviously. > >>> > >>> Number 2 is just something I need to fix. Number 1 is problematic, > >>> and I'd like your feedback on that. Have you looked at the ip6_gre > >>> code? > > I looked at ip6_gre when it first arrived, but have not done any > > real tests with it. > > > > Perhaps the internal skb header pointers are not properly in the > > sendmsg() path. It would probably require some debugging where the > > packets get dropped. > I found it. If ip6_gre is used without remote address, it sets > capability CAP_PER_PACKET. When sending packets, only CAP_XMIT is > checked, which is not set. I have a small patch for this now, > submitted to the very crowded netdev mailing list. No response yet. Nice. Yeah, response can take some days. > >> But not an issue actually, though not a fan of the code duplication > >> here for sysdep_netlink.c, this is TODO. > >> > >>> From what I see, what else needs to be changed: > >>> - The address_is_multicast function > >> Fixed. > >>> - is_any_address function > >> Fixed. > >>> - the broadcast address function (In IPv6 there is no subnet > >>> broadcast) > >> Fixed. > >>> - The netlink code assumes IPv4 in a couple of places. > >> Fixed. > >>> Did I miss something? > >> Well, I guess that is still open ;-) > > On quick glance the patches look mostly ok. I probably have some > > comments. But I want to take a closer look at them first. I'll try > > to do it this week sometime. > > > At least 1 thing was still wrong with these patches: I do not set the > interface protocol address. But then I didn't because it didn't make > sense to have 1 address there, as there may well be more addresses. I > need to have a closer look at this, but setting > iface->protocol_address at least works enough for exchanges to start > happening. Using link-local addresses is sufficient here, though for > some BGP programs where the interface cannot be specified it may be > good to also have extra addresses on the interface checked against. > This requires some more testing though. Ok. > Another thing is that I have not patched the BPF pfpacket stuff, so no > multicast forwarding. Patching the BPF stuff is hurting my brain and > may take quite some time, pretty sure I don't have that time this > week though. > > Though using it with IPv6 without multicast is already pretty useful > with BGP route reflectors. That may scale way better than doing > multicast anyway.. BPF is used for two things: multicast, and figuring out when to send traffic indications. By default you'll get all traffic which is ok, the BPF is used just to limit the traffic to the one we are really interested about. In fact, I would like to get rid of the BPF completely and use either netfilter/ulog, or some other mechanism to get even further limited notifications from the kernel. The problem with BPF currently is that if you have a flow that cannot establish direct tunnel (e.g. both parties are NATted), you'll end up getting all of that traffic to opennhrp. Just transferring all that data between kernel and userland can take noticeable amount of CPU time. /Timo ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ opennhrp-devel mailing list opennhrp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opennhrp-devel
