On Tue, Jul 04, 2017 at 09:15:49AM +, Florian Obser wrote:
> Comments, OKs?
>
s/saddr6 musst/saddr6 must/
then ok
> diff --git nd6_nbr.c nd6_nbr.c
> index fa8d3ed1472..086eeef87ba 100644
> --- nd6_nbr.c
> +++ nd6_nbr.c
> @@ -445,7 +445,8 @@ nd6_ns_output(struct ifnet *ifp, struct in6_addr
Am 07/04/17 um 11:15 schrieb Florian Obser:
> Marc, does this fix your problem?
>
> Comments, OKs?
>
> diff --git nd6_nbr.c nd6_nbr.c
> index fa8d3ed1472..086eeef87ba 100644
> --- nd6_nbr.c
> +++ nd6_nbr.c
> @@ -445,7 +445,8 @@ nd6_ns_output(struct ifnet *ifp, struct in6_addr *daddr6,
>
On Mon, Jul 03, 2017 at 11:13:30PM +0200, Patrik Lundin wrote:
> On Sun, Jul 02, 2017 at 06:04:30PM +, Florian Obser wrote:
> > > It'd be nice if somebody could tell us what the RFCs say about this
> > > case. Florian do you have an idea? Should we fix something or should
> > > Marc tell his
On Sun, Jul 02, 2017 at 06:04:30PM +, Florian Obser wrote:
> > It'd be nice if somebody could tell us what the RFCs say about this
> > case. Florian do you have an idea? Should we fix something or should
> > Marc tell his provider to fix his setup?
>
> this was introduced by claudio@ in
On Mon, Jun 26, 2017 at 01:34:37PM +0200, Martin Pieuchot wrote:
> On 26/06/17(Mon) 12:39, Marc Peters wrote:
> > Am 06/26/17 um 10:58 schrieb Martin Pieuchot:
> > > [...]
> > > Could you set net.inet6.icmp6.nd6_debug to 1 and redo this?
> > >
> > > Do you see anything in the log?
> >
> >
Did you open a trouble ticket on Hetzner?
2017-06-26 8:34 GMT-03:00 Martin Pieuchot :
> On 26/06/17(Mon) 12:39, Marc Peters wrote:
> > Am 06/26/17 um 10:58 schrieb Martin Pieuchot:
> > > [...]
> > > Could you set net.inet6.icmp6.nd6_debug to 1 and redo this?
> > >
> > > Do
Am 06/26/17 um 10:58 schrieb Martin Pieuchot:
> On 22/06/17(Thu) 17:59, Marc Peters wrote:
>> Am 06/22/17 um 16:51 schrieb Stefan Sperling:
>>> On Thu, Jun 22, 2017 at 04:05:27PM +0200, Marc Peters wrote:
Is there any way for us to fix it or is it just a misconfiguration at
Hetzner?
>>>
On Mon, Jun 26, 2017 at 11:29:06AM +0200, Marc Peters wrote:
> Haven't got time to rebuild the kernel with debug options yet, or is
> this not needed?
Not needed. Just run sysctl net.inet6.icmp6.nd6_debug=1
On 22/06/17(Thu) 17:59, Marc Peters wrote:
> Am 06/22/17 um 16:51 schrieb Stefan Sperling:
> > On Thu, Jun 22, 2017 at 04:05:27PM +0200, Marc Peters wrote:
> >> Is there any way for us to fix it or is it just a misconfiguration at
> >> Hetzner?
> >
> > It might help to look at what is actually
Am 06/22/17 um 16:51 schrieb Stefan Sperling:
> On Thu, Jun 22, 2017 at 04:05:27PM +0200, Marc Peters wrote:
>> Is there any way for us to fix it or is it just a misconfiguration at
>> Hetzner?
>
> It might help to look at what is actually going over the wire
> while pings are stuck: tcpdump -n
Am 06/22/17 um 16:49 schrieb Stuart Henderson:
> On 2017/06/22 16:05, Marc Peters wrote:
>> Am 06/22/17 um 15:30 schrieb Stuart Henderson:
>>>
>>> How are your PF rules? Do they allow NDP packets to pass? If you're
>>> unsure, I would try "pass log inet6 proto icmp6" or similar.
>>>
>>> (this
On Thu, Jun 22, 2017 at 04:05:27PM +0200, Marc Peters wrote:
> Is there any way for us to fix it or is it just a misconfiguration at
> Hetzner?
It might help to look at what is actually going over the wire
while pings are stuck: tcpdump -n -i em0 ip6
On 2017/06/22 16:05, Marc Peters wrote:
> Am 06/22/17 um 15:30 schrieb Stuart Henderson:
> >
> > How are your PF rules? Do they allow NDP packets to pass? If you're
> > unsure, I would try "pass log inet6 proto icmp6" or similar.
> >
> > (this might be a bit of a surprise if used to IPv4 where
Am 06/22/17 um 15:30 schrieb Stuart Henderson:
>
> How are your PF rules? Do they allow NDP packets to pass? If you're
> unsure, I would try "pass log inet6 proto icmp6" or similar.
>
> (this might be a bit of a surprise if used to IPv4 where address
> resolution is done by a separate protocol
On 2017/06/22 14:13, Marc Peters wrote:
> Hi,
>
> i have a server at the german hosting provider Hetzner. They provide
> IPv6. You get a /64 assigned for your host. The problem is, that IPv6
> doesn't work right after a reboot, but you have to ping the gateway
> first and after that, everything
crontab:
@reboot sleep 10 && ping6 -c 10 fe80::1\%em0 > /dev/null
mpi@ suggested to stop working around this and fixing it. He asked for
the output of the routing table before pinging the gateway without IPv6
access and after pinging the gateway with working IPv6.
Before:
~ $ route -n s
16 matches
Mail list logo