Am 28.08.2015 um 11:27 schrieb Alexander Holler:
Am 28.08.2015 um 09:36 schrieb Martin KaFai Lau:
On Mon, Aug 17, 2015 at 11:43:20AM +0200, Alexander Holler wrote:
That's why I vote to check out if it's possible/reasonable to
backport this
series to the stable kernels.
I have bac
Am 28.08.2015 um 09:36 schrieb Martin KaFai Lau:
On Mon, Aug 17, 2015 at 11:43:20AM +0200, Alexander Holler wrote:
That's why I vote to check out if it's possible/reasonable to backport this
series to the stable kernels.
I have backported to 4.0.y without major issue, so possible.
Am 15.08.2015 um 09:48 schrieb Alexander Holler:
Am 30.07.2015 um 13:57 schrieb Alexander Holler:
Am 29.07.2015 um 11:25 schrieb Alexander Holler:
Am 23.05.2015 um 05:55 schrieb Martin KaFai Lau:
To complete the discussion, that "annoying behaviour" is also a big
information leak
Am 30.07.2015 um 13:57 schrieb Alexander Holler:
Am 29.07.2015 um 11:25 schrieb Alexander Holler:
Am 23.05.2015 um 05:55 schrieb Martin KaFai Lau:
This series is to avoid creating a RTF_CACHE route whenever we are
consulting
the fib6 tree with a new destination. Instead, only create
Am 29.07.2015 um 11:25 schrieb Alexander Holler:
Am 23.05.2015 um 05:55 schrieb Martin KaFai Lau:
This series is to avoid creating a RTF_CACHE route whenever we are
consulting
the fib6 tree with a new destination. Instead, only create RTF_CACHE
route
when we see a pmtu exception.
That even
world because
it avoids the IPv6 route add/delete pairs which happened before whenever
an IPv6-connection was tried (e.g. by Happy Eyeballs algorithms).
I think that's worse a laud. thanks.
Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe netdev" i
Am 26.05.2015 um 16:36 schrieb Alexander Holler:
Am 26.05.2015 um 14:10 schrieb Nicolas Dichtel:
I don't understand why dumping in another netns is a problem.
It isn't. I just wondered how you (or someone else) is using
NETLINK_LISTEN_ALL_NSID, assuming it already serves a purpose.
Am 26.05.2015 um 14:10 schrieb Nicolas Dichtel:
Le 26/05/2015 12:53, Alexander Holler a écrit :
Am 25.05.2015 um 15:09 schrieb Nicolas Dichtel:
[snip]
Hmm, sounds like we're talking in different rooms about the same thing
in regard
to the dump. ;)
I just wanted to explain why I think
Am 25.05.2015 um 15:09 schrieb Nicolas Dichtel:
Le 25/05/2015 12:55, Alexander Holler a écrit :
Am 25.05.2015 um 09:45 schrieb Nicolas Dichtel:
Le 22/05/2015 22:50, Alexander Holler a écrit :
First I think if NETLINK_LISTEN_ALL_NSID is enabled, a dump
of the interfaces through RTM_GETLINK
Am 25.05.2015 um 09:45 schrieb Nicolas Dichtel:
Le 22/05/2015 22:50, Alexander Holler a écrit :
First I think if NETLINK_LISTEN_ALL_NSID is enabled, a dump
of the interfaces through RTM_GETLINK together with NLM_F_DUMP and
NLM_F_REQUEST should return all interfaces of all reachable namespaces
Am 22.05.2015 um 23:29 schrieb Cong Wang:
On Fri, May 22, 2015 at 2:12 PM, Alexander Holler wrote:
Bridge doesn't have an underlying link, so no LINK_NETNSID. LINK_NETNSID
is only added when its underlying link is in a different netns.
I'm using "link" similiar as inte
Am 22.05.2015 um 23:19 schrieb Eric W. Biederman:
Alexander Holler writes:
Am 08.05.2015 um 14:02 schrieb Eric W. Biederman:
So I am dense. I have read through the patches and I don't see where
you tag packets from other network namespaces with a network namespace
id.
Me too,
You
Am 22.05.2015 um 23:04 schrieb Cong Wang:
On Fri, May 22, 2015 at 1:50 PM, Alexander Holler wrote:
Am 08.05.2015 um 14:02 schrieb Eric W. Biederman:
So I am dense. I have read through the patches and I don't see where
you tag packets from other network namespaces with a network name
omething, I'm doing something wrong,
or there still is some work todo to make NETLINK_LISTEN_ALL_NSID work
like expected (or like my simple mind would expect it).
Thanks again for the patches, regards,
Alexander Holler
--
To unsubscribe from this list: send the line "unsubscri
14 matches
Mail list logo
