netdev - Re: IPv6 path discovery oddities - flushing the routing cache resolves

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20131018030440.GI18135@order.stressinduktion.org>
Date:	Fri, 18 Oct 2013 05:04:40 +0200
From:	Hannes Frederic Sowa <hannes@...essinduktion.org>
To:	Valentijn Sessink <valentyn@...b.net>
Cc:	netdev@...r.kernel.org
Subject: Re: IPv6 path discovery oddities - flushing the routing cache resolves

On Thu, Oct 17, 2013 at 12:53:56PM +0200, Valentijn Sessink wrote:
> Hi,
> 
> Thanks for your fast response, please see below. Sorry for the rather 
> long mail, due to the routing tables. Even though they're really short, 
> the output of ipv6_route is extensive...
> 
> On 16-10-13 17:48, Hannes Frederic Sowa wrote:
> >I do think these two issues are connected. Could you send me a the
> >corresponding ip route output and /proc/net/ipv6_route output for when it
> >works and mtus are correctly handled and when it does not work?
> 
> When it works (please note that the routing cache at first doesn't show 
> an MTU, that only happens after a "too big" has been received, hence the 
> difference before and after a "ps uaxww"), I have the following - this 
> is from last night:

Thanks, I needed this to verify I am on the right track replicating this.
2001:1af8:ff03:3:219:66ff:fe26:6dd is the other end of the connection, I
guess?

Greetings,

  Hannes

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html