On 09/11/16(Wed) 20:49, Gregor Best wrote:
> Hi,
>
> On Mon, Nov 07, 2016 at 03:55:29PM +0100, Gregor Best wrote:
> > [...]
> > I can't reproduce the problem anymore. If it does turn up again, I'll
> > collect the output of route monitor. In the mean time, thanks a bunch
> > for your help :)
> >
Hi,
On Mon, Nov 07, 2016 at 03:55:29PM +0100, Gregor Best wrote:
> [...]
> I can't reproduce the problem anymore. If it does turn up again, I'll
> collect the output of route monitor. In the mean time, thanks a bunch
> for your help :)
> [...]
It happened again, this time in a slightly more
Hi,
On Mon, Nov 07, 2016 at 09:12:12AM +0100, Martin Pieuchot wrote:
> [...]
> Could you capture the route changes via "# route monitor"? I'd like
> to know if the 'bad gateway value' message is triggered by userland
> or the kernel.
> [...]
I can't reproduce the problem anymore. If it does
On 05/11/16(Sat) 19:26, Gregor Best wrote:
> [...]
> If I can do anything else to be of assistance, please let me know.
Could you capture the route changes via "# route monitor"? I'd like
to know if the 'bad gateway value' message is triggered by userland
or the kernel.
Hi Martin,
On Fri, Nov 04, 2016 at 11:44:14AM +0100, Martin Pieuchot wrote:
>
> That's the problem. The entry is flagged as RTF_LLINFO but contains an
> IPv6 address.
>
> Do you see any other errors in /log/messages?
>
Only
nd6_rtrequest: bad gateway value: tap0
immediately before
On 30/10/16(Sun) 02:02, Gregor Best wrote:
> Hi,
>
> On Mon, Jun 06, 2016 at 07:16:20PM +0200, Martin Pieuchot wrote:
> > [...]
> > + if (rt->rt_gateway->sa_family != AF_LINK) {
> > + printf("%s: something odd happens\n", __func__);
> > + m_freem(m);
> > + return
Hi,
On Mon, Jun 06, 2016 at 07:16:20PM +0200, Martin Pieuchot wrote:
> [...]
> + if (rt->rt_gateway->sa_family != AF_LINK) {
> + printf("%s: something odd happens\n", __func__);
> + m_freem(m);
> + return (EINVAL);
> + }
> [...]
I noticed that since a
On 06/06/16(Mon) 16:40, Martin Pieuchot wrote:
> Various functions in our ND implementation look at the type of the
> sending interface to decide what they should do. Recently sthen@
> found a regression on his p2p link because nd6_output() was doing
> a check that only makes sense for Ethernet
Various functions in our ND implementation look at the type of the
sending interface to decide what they should do. Recently sthen@
found a regression on his p2p link because nd6_output() was doing
a check that only makes sense for Ethernet interfaces.
So instead of "skipping" p2p interface in
