Fix blackhole/reject routes.

[melifaro]

Summary

Traditionally *BSD routing stack required to supply some
interface data for blackhole/reject routes. This lead to
varieties of hacks in routing daemons when inserting such routes.
With the recent routeing stack changes, gateway sockaddr without
RTF_GATEWAY started to be treated differently, purely as link
identifier.

This change broke net/bird, which installs blackhole routes with
127.0.0.1 gateway without RTF_GATEWAY flags.

Fix this by automatically constructing necessary gateway data at
rtsock level if RTF_REJECT/RTF_BLACKHOLE is set.

[donner]

sys/net/rtsock.c

571

Why do you check here. that setting both flags together is an error? If it's about blackholing, just check for the RTF_BLACKHOLE. If RTF_REJECT uses the same approach, compare against zero.

Given, that you check the flags before calling again, I'd leave out the test here.

[melifaro]

sys/net/rtsock.c

571

Not sure I fully understand the comment, but let me clarify:

Handling for blackhole and reject is almost identical: both don't care about the gateway and use loopback as an address.
However, blackhole and reject are mutually exclusive: the former instructs to drop the packet, the latter - to drop the packet and send ICMP error message.

Handling similarity is the reason for using single function and jump based on either of these.
Mutual exclusiveness is the reason for having the check here rejecting reject+blackhole combination.

I hope it provides a bit more clarity.

[donner]

sys/net/rtsock.c

571

I'm only surprised, that this input parameter check is part of this function, instead of part of the calling routine. So the test for the flags are split over the code.