On Wed, 20 Aug 2003, YOSHIFUJI Hideaki / [iso-2022-jp] 吉藤英明 wrote:
> In article <Pine.LNX.4.44.0308201423500.541-200000@xxxxxxxxxxxxxxx> (at Wed,
> 20 Aug 2003 14:40:14 +0300 (EEST)), Ville Nuorvala <vnuorval@xxxxxxxxxx> says:
>
> > --- linux-2.5.OLD/net/ipv6/ndisc.c 2003-08-20 14:10:16.000000000 +0300
> > +++ linux-2.5/net/ipv6/ndisc.c 2003-08-20 14:10:30.000000000 +0300
> > @@ -861,7 +861,8 @@
> > struct inet6_dev *in6_dev = in6_dev_get(dev);
> >
> > if (in6_dev && in6_dev->cnf.forwarding &&
> > - (addr_type & IPV6_ADDR_UNICAST) &&
> > + (addr_type & IPV6_ADDR_UNICAST ||
> > + addr_type == IPV6_ADDR_ANY) &&
> > pneigh_lookup(&nd_tbl, &msg->target, dev, 0)) {
> > int inc = ipv6_addr_type(daddr)&IPV6_ADDR_MULTICAST;
> >
>
> I believe we don't need this chunk.
No, it is needed. Normal neighbor solicitations are sent using a unicast
source address, but DAD probes are sent using the unspecified address as
source.
If the check for IPV6_ADDR_ANY isn't done right there, the proxy won't
handle the DAD probes, since it never enters the shown if block.
The new
if (addr_type & IPV6_ADDR_UNICAST) {
...
} else { <- addr_type == IPV6_ADDR_ANY
...
}
block inside it handles the different cases sending a unicast NA to a
normal NS and a multicast NA to a DAD.
I've updated the comment in my new patch to clarify this. Please use it
instead.
Regards,
Ville
--
Ville Nuorvala
Research Assistant, Institute of Digital Communications,
Helsinki University of Technology
email: vnuorval@xxxxxxxxxx, phone: +358 (0)9 451 5257
proxy_dad_v2.patch
Description: Text document
|