On 07/01/15(Wed) 19:00, Florian Riehm wrote:
Hi Martin,
Thanks for your diff! Regardless of my problem it makes our code
more clear. The loop in rt_newaddrmsg() was ugly.
Here's a diff that should generate a RTM_ADD message for every CLONING
route added while keeping the existing
On Mon, Jan 12, 2015 at 03:00:41PM +0100, Martin Pieuchot wrote:
@@ -1138,7 +1140,8 @@ rt_ifa_add(struct ifaddr *ifa, int flags
* userland that a new address has been added.
*/
if (flags RTF_LOCAL)
- rt_newaddrmsg(RTM_ADD, ifa,
Hi Martin,
Thanks for your diff! Regardless of my problem it makes our code
more clear. The loop in rt_newaddrmsg() was ugly.
Here's a diff that should generate a RTM_ADD message for every CLONING
route added while keeping the existing RTM_NEWADDR/RTM_DELADDR logic.
dhclient(8) is happy
On 23/12/14(Tue) 14:43, Florian Riehm wrote:
On 12/23/14 11:59, Martin Pieuchot wrote:
Would it make sense to remove the loop in rt_newaddrmsg which generates
the two
route messages? Instead of this rt_newaddrmsg sends only the RTM_NEWADDR
/
RTM_DELADDR message and the other
Hi Martin,
as requested in your commit message I would like to tell you about a regression
with the introduced local routes:
Before OpenBSD 5.6 it was possible to add route labels to interfaces and tell
ospfd to redistribute all labeled routes. After adding an address to a labeled
interface a
Hello Florian,
On 23/12/14(Tue) 11:17, Florian Riehm wrote:
Hi Martin,
as requested in your commit message I would like to tell you about a
regression
with the introduced local routes:
Before OpenBSD 5.6 it was possible to add route labels to interfaces and tell
ospfd to redistribute
On 12/23/14 11:59, Martin Pieuchot wrote:
Would it make sense to remove the loop in rt_newaddrmsg which generates the
two
route messages? Instead of this rt_newaddrmsg sends only the RTM_NEWADDR /
RTM_DELADDR message and the other message gets send after
creating/deleting the
cloning
