| Age | Commit message (Collapse) | Author |
|---|
|
ok jmc
|
|
In the case of an error, we want to return as soon as possible to avoid
having to clean things up.
This fixes a bug where we could create a dynamic targeted neighbor in
response to a malformed packet.
|
|
Fixes the following ANVL LDP tests: 1.5 and 9.4.
|
|
This is basically just to make ANVL happy, there's not much difference
between sending an 'Unknown FEC' or a 'Malformed TLV' Notification.
Fixes ANVL LDP test 15.6.
|
|
Also, add one more safety check in recv_init().
|
|
In the parsing of label and notification messages, we were always
unsetting the first bit of the TLV type before comparing it against the
types we know. We should not do this because our type constants can have
this bit set when appropriate.
By now the only unknown TLV supported by ldpd(8) is TLV_TYPE_DUALSTACK,
which is only used in Hello messages. But we might change this in the
future with support for MAC List TLVs and maybe RFC 7473.
|
|
This doesn't fix any bug as we were already using uint16_t everywhere
else.
|
|
We were accepting at most one optional TLV.
Fixes IxANVL LDP test 15.3.
|
|
|
|
read_mem() and write_mem() in vmd(8) now use memcpy() instead of the
vm_readpage() and vm_writepage() ioctls to read/write guest memory.
ok mlarkin@
|
|
Pointed out by Frank Schoep, thanks!
|
|
In the original LDP specification, there was no circumstance where a
Notification message could be sent in response to a Hello message. So
setting the Message ID field for Hello packets was useless.
This changed with RFC 7552, where Hello packets can trigger the "Transport
Connection Mismatch" notification when the local and remote transport
preferences doesn't match. In this case, having a meaningful Message ID
in the Hello packets can aid in testing and troubleshooting.
|
|
RFC 5036 says the following about the receipt of unknown messages:
"Unknown message bit. Upon receipt of an unknown message, if U is
clear (=0), a notification is returned to the message originator;
if U is set (=1), the unknown message is silently ignored".
We were correctly ignoring unknown messages when the U-bit was set. But
when this bit was not set, we were shutting down the session when the
correct thing to do is to just send a non-fatal notification message.
Fix IxANVL LDP test 22.13.
|
|
RFC 5036 says:
"When the last Hello adjacency for an LDP session is
deleted, the LSR terminates the LDP session by sending a Notification
message and closing the transport connection".
Send a "Hold Timer Expired" notification when the triggering event is
a hello hold time timeout. In the other cases, like disabling LDP on an
interface, send a "Shutdown" notification instead.
Before this patch we were just closing the neighbor's transport
connection.
Fixes the following ANVL LDP tests: 7.17 and 23.3.
|
|
When the transport address is changed, we can't try to reconnect to the
neighbors inside merge_af() because the ldpe process still didn't receive
the new network sockets from the parent at this point. To resolve this,
try to reconnect just after we receive these sockets.
|
|
IxANVL LDP test 5.13 was failing for ldpd(8) because we were not
discarding IPv4 Hello messages with an IPv6 transport address (and
vice-versa).
Once again, the RFC is not very explicit about what to do in this
case. Since the IPv4 and IPv6 Transport Address TLVs are optional,
what we were doing is to just ignore them in this case and use source
address of the packet as the implicit transport address.
But the IxANVL team had a different interpretation on this. They think
that discarding the Hello message is the right thing to do in this case.
Let's follow their interpretation because that's probably what most
implementations are doing.
NOTE1: with this patch we still keep ignoring additional Transport Address
TLVs as specified in RFC 7552;
NOTE2: in order to check if a Transport Address TLV was already received
or not, use the F_HELLO_TLV_RCVD_ADDR flag instead of comparing if the
address is zero or not (easier to read).
Fixes IxANVL LDP test 5.13.
|
|
RFC 5036 says the following:
"It is possible for a pair of incompatibly configured LSRs that
disagree on session parameters to engage in an endless sequence of
messages as each NAKs the other's Initialization messages with Error
Notification messages.
An LSR MUST throttle its session setup retry attempts with an
exponential backoff in situations where Initialization messages are
being NAK'd".
The problem here is that the RFC is not very explicit of what can be
a NACK. We were considering only the following notification messages
as NACKs:
* Session Rejected/No Hello;
* Session Rejected/Parameters Advertisement Mode;
* Session Rejected/Parameters Max PDU Length;
* Session Rejected/Parameters Label Range;
* Session Rejected/Bad KeepAlive Time.
It turns out that some implementations can NACK with a Shutdown
notification. And there's the possibility of other implementations using
different notifications as well.
To fix this, consider any fatal notification as a NACK when the neighbor
is in the OPENSENT state (i.e. we sent an Initialization and we're
waiting for a response).
Fixes the following ANVL LDP tests: 6.19, 6.21 and 6.22
|
|
RFC 5036 says the following about the "Receiver LDP Identifier" field:
"Identifies the receiver's label space. This LDP Identifier, together
with the sender's LDP Identifier in the PDU header, enables the receiver
to match the Initialization message with one of its Hello adjacencies;
If there is no matching Hello adjacency, the LSR MUST send a Session
Rejected/No Hello Notification message in response to the Initialization
message and not establish the session".
This is one more case of LDP being more complex than what it should have
been. Since LDP support MPLS label spaces (for ATM and FR), just the
sender's LSR-ID in the PDU header is not enough for identifying an Hello
adjacency. We also need the receiver's label space, and that's what this
field gives us. In fact, this field contains the full receiver's LSR-ID,
but the IP part doesn't really matter.
Since we don't support label spaces (and never will), we were happily
ignoring this field. This patch changes this to fix some errors with ANVL.
Fixes the following ANVL LDP tests: 6.5, 6.6 and 6.11.
|
|
diff by Pavel Korovin <p@tristero.se>, ok giovanni@
|
|
vmm(4) then maps the pages allocated by the vmd(8) user process into the
address space of the guest. This gives vmm(4) and vmd(8) a shared view of
the guest RAM. This will allow us to have faster guest<->host data
exchange by ordinary memory loads/stores later, as well as remove the
vm_readpage and vm_writepage ioctls next.
ok mlarkin@
|
|
-portable
|
|
ok gilles@
|
|
When ldpe requests new network sockets to the parent process (after the
transport-address is changed), it must specify the desired address-family
(IPv4 or IPv6). We can use the 'pid' or 'peerid' members of the imsg_hdr
structure for this. Use 'pid' for convenience (no need to extend the
wrapper function, ldpe_imsg_compose_parent()).
|
|
session.c
ok mpi@
|
|
warning in rde.c
|
|
warning in rde.c
ok stsp@
|
|
If we change a neighbor's password or the global transport-address,
cancel the affected pending connects and, when playing the active role
of the session establishment process, try to connect again right away
with the new password and/or transport-address.
Without this patch we have to wait for the timeout of the pending
connects, which might be a lot of time.
|
|
|
|
only relevant for pkg_add/pkg_delete.
Every tool needs an interactive object, but setting that to InteractiveStub
"just in case" after doing the interactive dance is fine for
pkg_create/pkg_sign
problem noticed by jsg@ in pkg_sign(1).
|
|
spinning on them, trying to preemptively avoid kevent. i've come to
conclude this is a poor design. it is exceedingly rare for there to be
two requests waiting. instead, we end up burning useless syscalls.
|
|
The fork+exec diff introduced this problem where we were indirectly
calling imsg_event_add() before initializing (event_set) iev_rde and
iev_eigrpe. Fix this by moving down both main_imsg_send_ipc_sockets()
and main_imsg_send_config(), after iev_rde and iev_eigrpe are
initialized.
benno@ reported this problem for the initial ospfd fork+exec attempt,
now fix eigrpd too.
ok deraadt
|
|
For EIGRPv6, an interface only needs an link-local address in order
to be enabled in the routing daemon. So adding or removing global
unicast addresses, for example, will never trigger a state change in
the interface.
Additionally, move all address handling code to if_addr_new() and
if_addr_del() to improve readability.
|
|
The uptime was being set only when the interface was created, which is
not what we want.
|
|
make it an error otherwise instead of a warning that may be overlooked.
reported by Peter van Dijk
ok deraadt
|
|
banners, introduce lmtp_banner() which takes care of this.
ok sunil@
|
|
continuation lines, fix this.
reported and initial diff by parchd-1 @ github, ok sunil@
|
|
For each child process (rde and eigrpe), re-exec eigrpd with a special
"per-role" getopt flag. This way we have seperate ASLR/cookies per
process.
Based on a similar patch for bgpd, from claudio@
ok deraadt
|
|
|
|
The shed fell over because 15 layers of paint exceeded engineering margins.
|
|
filters (AS, peer-as, source-as, transit-as).
Add a use case (block illegal AS numbers) to the bgpd.conf example.
feedback from claudio, sthen, florian,
ok florian@ phessler@
|
|
ok gilles
|
|
searching for a linux partition type, now it looks for a fat type.
ok kettenis@
|
|
became more visible recently because a log_debug was changed to
log_warnx. Change it back for now.
ok jsing
|
|
creating more copies.
ok deraadt@, jsing@
|
|
but still needs to be before pledge. also check for failure.
|
|
From Fabian Raetz <fabian dot raetz at gmail dot com>
|
|
There's no need to have a separate case for non-CIDR addresses using
inet_pton(3) as inet_net_pton(3) handles them as well.
This simplification is valid for all our daemons parsing addresses,
it is a common patern.
ok gilles@, millert@
|
|
that are tested by the main loop.
ok jca@ deraadt@
|
|
The parent process forks child processes and re-exec each of them with
an additional "-x <proc>" argument. During the early setup phase, the
parent process sends ipc socket pairs to interconnect the child
processes as needed, and it passes the queue encryption key to the
queue if necessary. When this is done, all processes have their
environment set as in the fork-only case, and they can start doing
their work as before.
ok gilles@ jung@
|
|
ok deraadt jca
|
