From: <cz...@li...> - 2011-10-26 17:40:36
|
Hi Linda If you recall we had a discussion earlier in the year about how xinetd was not working for me in the netfiltering tests. I have since retried and it appears to work significantly better now. I did notice a couple odd things which I have not fully investigated yet. One of those involves the ipv6 addresses and how the netcat (nc) is handled when running xinetd vs lblnet_tst_server started manually without xinetd running. It appears the networking tests (not ipsec just yet but the others) will work just fine as long as the ipv6 address is a global address, it definitely has some problems when the address is link local. (I suspect site local would work just fine also) I think the problem is that netcat requires the optional device name attached after the ipv6 address when the ipv6 address is a link local(for example nc -w 1 fe80::214:66fe:54ff:ef60%eth0)where as when the address is a global or site local it does not. I think the issue is in addr_filter.bash in the function get_ipv6_iface. The ip command in the function does a show scope global to $LBLNET_PREFIX_IPV6. If the LBLNET_SVR_IPV6 environmental variable is set to a link local IPV6 address, I'm guessing the expectation is $LBLNET_PREFIX_IPV6 will have a link local prefix (i.e fe80::/64). So the return from the ip command will have nothing in it as opposed to eth0 when the $LBLNET_PREFIX_IPV6 is set to a global prefix. I tested this out by simply changing the show scope global to a show scope link and this worked ok, but I think a check for whether the prefix is link local or global may be required before first followed by an ip command using show scope link if the address is link local. Even with a test copy that essentially does the change suggested above there is still one peculiarity when running with xinetd. That is on test cases where the network server needs to initiate the conversation (such as TOE test cases utilizing do_accept, do_recvfrom, and do_read) In the IPV6 case (using link local addresses only) where the host value is remote (as opposed to local) the test case always errors out. A tcpdump of these cases shows that the after the setup the packets are not sent. These test cases work correctly when lblnet_tst_server is started from the network-server directory and xinetd is not run. I'm wondering if the TOE ipv6 link local address being passed with the scope attached is causing xinetd problems? Anyway still looking at some of this Maybe we can talk about it when you get back. Sorry this was lengthy Jim |
From: Paul M. <pa...@pa...> - 2011-10-26 20:28:12
|
On Wednesday, October 26, 2011 01:27:12 PM cz...@li... wrote: > ... It appears the networking tests (not ipsec just yet but the > others) will work just fine as long as the ipv6 address is a global > address, it definitely has some problems when the address is link > local. During the RHEL5 time frame IPsec would fall flat on its face when using scoped IPv6 addresses so we moved to global addresses. I could be wrong, but I imagine this limitation may still exist. I would recommend sticking with global addresses. -- paul moore www.paul-moore.com |
From: Ondrej M. <om...@re...> - 2011-10-26 20:43:35
|
On 10/26/2011 10:27 PM, Paul Moore wrote: > On Wednesday, October 26, 2011 01:27:12 PM cz...@li... wrote: >> ... It appears the networking tests (not ipsec just yet but the >> others) will work just fine as long as the ipv6 address is a global >> address, it definitely has some problems when the address is link >> local. > > During the RHEL5 time frame IPsec would fall flat on its face when using > scoped IPv6 addresses so we moved to global addresses. I could be wrong, but > I imagine this limitation may still exist. > > I would recommend sticking with global addresses. > Currently, ipsec tests in trustedprograms work with IPv6 addresses of global scope only. It might be interesting to test them with site local (if possible, I have never tried). However, the question is - do we need it (just asking, I am really curious)? -- Ondrej Moriš, RHCE Quality Assurance Engineer BaseOS QE - Security Email: om...@re... Web: www.cz.redhat.com IRC: omoris at #qa #urt #brno, #penguins Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic |