Index: [Article Count Order] [Thread]

Date: Mon, 30 Mar 2009 17:01:07 +0900
From: Hiroki ENDO <velo@tahi.org>
Subject: [users:01150] Re: Question about Interoperability test 1.2.B (host)
To: Bin Zhang <Bin.Zhang@secure64.com>
Cc: users@tahi.org
Message-Id: <20090330170107.b0bd428f.velo@tahi.org>
In-Reply-To: <49B981B5.4070509@secure64.com>
References: <49B1D0A6.2010304@secure64.com>	<200903071041.FMLAAB31431.users@tahi.org>	<49B1D31E.9050002@secure64.com>	<49B20467.5020407@redhat.com>	<49B981B5.4070509@secure64.com>
X-Mail-Count: 01150

Hi Bin,

I observed the same behavior as you said.
I propose an idea to continue the interoperability test for your
information.

1. FreeBSD
As far as in source code, it seems that FreeBSD supports RFC4862
Section 5.4.5 behavior.  If a duplicate address is a link-local
address formed from EUI-64, FreeBSD disables IP operation.

I think that FreeBSD behaves correctly. If we use FreeBSD as Target
Node, we need to use a link-local address which is not formed from
EUI-64 or a global address as a duplicate address.


2. NetBSD
I could observe DAD NS for a link-local address, when the box booted.
And I also could observe DAD NS for a global address at any time.
But I could not any DAD NS for link-local address after boot.

I do not know the cause, it may be network card issue as Jiabo said.
If we use NetBSD as Target Node, we may use a global address as a
duplicate address.

Thanks,
--
Hiroki ENDO


On Thu, 12 Mar 2009 15:42:13 -0600
Bin Zhang <Bin.Zhang@secure64.com> wrote:

> Hi Jiabo,
> 
> Thanks for your reply, I didn't figure out why FreeBSD 7.1 doesn't 
> recover from the DAD, but I had a work around on this which is to run 
> the test manually with out the vel tool and reboot the FreeBSD box 
> between the first and the second half of test 1.2.B.
> 
> However, I have another problem while running the NetBSD box as 
> target-host, which is, the NetBSD box does not send out Neighbor 
> Solicitations when the interface comes up, I saw you asked about this on 
> the web, I don't know if you have found out a solution yet, could you 
> give me some suggestions on this issue?
> 
> Thanks,
> Bin
> 
> wang_jiabo :
> > Bin Zhang wrote:
> >> Hi,
> >>
> >> I am running tahi interoperability test 1.2.B (host), using the vel 
> >> 4.0.0 tool. The TAR and REF machines are both FreeBSD 7.1, and LOGO 
> >> machine is our device.
> >>
> >> I have a question about FreeBSD 7.1 doing Duplicate Address Detection 
> >> (DAD).
> >>
> >> In the first half of the test, TAR detects there is a duplicated Link 
> >> Local Address (LLA) by doing DAD when the interface comes up, (the 
> >> LLA was manually configured on our device according to the vel tool's 
> >> instruction), after detecting the duplicate address, FreeBSD disables 
> >> IPv6 on that interface, and I see the following message in dmesg:
> >>
> >> em1: DAD detected duplicate IPv6 address fe80:4::217:a4ff:fe51:fb0d: 
> >> NS in/out=0/3, NA in=1
> >> em1: DAD complete for fe80:4::217:a4ff:fe51:fb0d - duplicate found
> >> em1: manual intervention required
> >> em1: possible hardware address duplication detected, disable IPv6
> >>
> >> After this, however, I can not get the IPv6 to be enabled back again, 
> >> ifconfig down/up (as the vel tool does) does not work, and all the 
> >> IPv6 traffic in the second half of the 1.2.B test is not being 
> >> generated/processed on that interface anymore. I tried to restart the 
> >> network by doing "/etc/rc.d/netif restart && sleep 30 && 
> >> /etc/rc.d/routing restart", it doesn't work either, the only thing I 
> >> can do is to reboot the box, but that forces the test script to lost 
> >> the connection, so the second half won't run.
> >>
> >> Could you give me any help on this issue?
> >>
> >> Thanks a lot!
> >> Bin
> > Hi, Bin:
> > did you use FreeBSD7.0 to try?
> > I think FreeBSD and NetBSD both need very old Network Card to test.
> > I hope these can give you some idea.
> > thanks
> > jiabo
> >
> >
>