On Sat, Sep 25, 2004 at 03:40:04AM +0900, JINMEI Tatuya / [EMAIL PROTECTED]@C#:H wrote:
> (resending, since the first attempt seems to have failed due to some
> DNS-related error)
>
> > On Thu, 23 Sep 2004 14:58:41 -0400,
> > Brian Fundakowski Feldman <[EMAIL PROTECTED]> said:
>
> >> So,
(resending, since the first attempt seems to have failed due to some
DNS-related error)
> On Thu, 23 Sep 2004 14:58:41 -0400,
> Brian Fundakowski Feldman <[EMAIL PROTECTED]> said:
>> So, as a result, I tend to think the proposed patch is a reasonable
>> fix to the problem. But please ad
On Fri, Sep 24, 2004 at 03:47:22AM +0900, JINMEI Tatuya / [EMAIL PROTECTED]@C#:H wrote:
> > On Tue, 21 Sep 2004 22:09:57 -0400,
> > Brian Fundakowski Feldman <[EMAIL PROTECTED]> said:
>
> > I've already made noise about this before, so I'll be brief. I plan on
> > committing the followin
> On Tue, 21 Sep 2004 22:09:57 -0400,
> Brian Fundakowski Feldman <[EMAIL PROTECTED]> said:
> I've already made noise about this before, so I'll be brief. I plan on
> committing the following fix that prevents the routing code from being
> recursed upon such that RTM_RESOLVE causes the e
On Tue, Sep 21, 2004 at 10:53:20PM -0400, Brian Fundakowski Feldman wrote:
> Sorry, I should have provided a higher number of lines of context.
> It prevents a call to nd6_lookup() and reentry into the route table
> when entered via RTM_RESOLVE. I.e. nd6_rtrequest(), nd6_is_addr_neighbor(),
> nd6_
On Wed, Sep 22, 2004 at 11:43:17AM +0900, George V. Neville-Neil wrote:
> At Tue, 21 Sep 2004 22:09:57 -0400,
> Brian Fundakowski Feldman wrote:
> >
> > I've already made noise about this before, so I'll be brief. I plan on
> > committing the following fix that prevents the routing code from bein
At Tue, 21 Sep 2004 22:09:57 -0400,
Brian Fundakowski Feldman wrote:
>
> I've already made noise about this before, so I'll be brief. I plan on
> committing the following fix that prevents the routing code from being
> recursed upon such that RTM_RESOLVE causes the embryonic new route to
> be loo
I've already made noise about this before, so I'll be brief. I plan on
committing the following fix that prevents the routing code from being
recursed upon such that RTM_RESOLVE causes the embryonic new route to
be looked up again. I realize that probably no one will bother trying
to see this bug
