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  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]
Date:   Mon, 2 Jan 2017 09:48:12 -0700
From:   David Ahern <>
To:     Olivier Brunel <>
Cc:, Alexander Duyck <>
Subject: Re: Bug w/ (policy) routing

On 1/1/17 12:52 PM, Olivier Brunel wrote:
> Indeed, if I first delete the rule for lookup local and recreate it
> w/ higher prio than my "lookup 50", then no more issue.

After the unshare or when creating a new network namespace, bringing the lo device up will create the local table and the rest of the commands will work properly. ie., instead of moving the local rule you can run:

unshare -n bash

ip li set lo up
ip rule add table 50 prio 50
ip link add test type veth peer name test2



The order of commands is influencing whether the unmerge succeeds or not which is wrong. I took a quick look and I don't see a simple solution to this. Effectively:

Adding a rule before bringing up any interface does not unmerge the tables:
$ unshare -n bash
$ ip rule add table 50 prio 50
$ ip li set lo up

In fib_unmerge(), fib_new_table(net, RT_TABLE_LOCAL) returns null.

Where the reverse order works:
$ unshare -n bash
$ ip li set lo up
$ ip rule add table 50 prio 50


Powered by blists - more mailing lists