| Age | Commit message (Collapse) | Author |
|---|
|
We need to use ldp_applymask() to normalize the received
prefixes. Example: 10.1.1.0/16 -> 10.1.0.0/16.
Additionally, stop using IANA's AF numbers in map->fec.prefix.af and use
AF_INET/AF_INET6 instead. This makes the code much simpler, use AF_IPV[46]
only when necessary (decoding/encoding prefixes).
ok claudio@
|
|
log_warnx()
ok renato@ claudio@
|
|
Also, use uint16_t for msg_type on gen_msg_hdr().
|
|
We must detect if a TLV's length extends beyond the end of the containing
message. And, if so, send a fatal "Bad TLV Length" notification message.
Found with the Mu Dynamics Mu-8000 protocol fuzzer.
|
|
Print "exp-null" and "imp-null" instead of "0" and "3", for example. Also,
remove print_label() and print_pw_type() from ldpctl.c and use the
equivalent functions from ldpd's log.c.
While here, be more paranoid and use UINT32_MAX instead of UINT_MAX
for NO_LABEL.
|
|
Since these are "well known" TLVs, we have to explicitly ignore them
otherwise ldpd would send "Unknown TLV" Notification messages when it
shouldn't.
Fixes regression caused by rev1.51.
|
|
|
|
The man page already contains the definition of the new neighbor-addr and
neighbor-id, but the examples were outdated. Now we may have an LSR-ID that
is different from its address.
ok renato@
|
|
|
|
No binary change after "strip -s".
|
|
When sending a label withdraw during the pseudowire Control Word
negotiation, append a "Wrong C-bit" status TLV after the FEC TLV (in
conformance to RFC 4447 section 6.2). Apparently this has no use other
than aiding in troubleshooting.
Also, extend the recv_labelmessage() function to accept Status TLVs and
ignore them instead of shutting down the session.
|
|
|
|
The previous value of 180 was just too long. If a neighbor get stuck in
the initialization FSM for more than 15 seconds, then there's certainly
something wrong and the session should be dropped.
A potential case of a neighbor getting stuck in the initialization
FSM is when both the local and the remote LSRs disable the LDPv4 GTSM
negotiation and there's a mismatch in their GTSM configuration (one is
enabled for GTSM while the other is not).
In this case, a smaller timeout allows for a quicker recovery of the
session when the configuration is fixed on either side.
|
|
Flag constants should start with F_.
|
|
This also finishes the missing bits from our RFC 7552 implementation
because GTSM is mandatory for LDPv6.
To avoid any kind of interoperability problems, I included a few
knobs to enable/disable GTSM on a per-address-family and per-neighbor
basis. Cisco's LDPv6 implementation, for instance, doesn't support GTSM.
"reads good" claudio@
|
|
Bug introduced by rev1.48 two weeks ago. We were not respecting the
advertised transport connection preference (LDPoIPv4 or LDPoIPv6),
the fix is pretty obvious.
|
|
|
|
tweaks from claudio@
|
|
change this in all config parsers in our tree that support macros.
problem reported by sven falempin.
feedback from henning@, stsp@, deraadt@
ok florian@ mikeb@
|
|
|
|
|
|
|
|
Configuring an interface for both LDP signaling and as a member of a
VPLS instance doesn't cause any harm as far as ldpd is concerned. But
it certainly doesn't make any sense, so it's better to reject the
configuration and warn the user instead of ignoring this silently.
|
|
|
|
LDP loop detection is only necessary for ATM LSRs running in cell mode. We
are never going to implement this "feature".
Also, add two more comments in lde_check_request().
|
|
ldpd operates only with the best routes of each IP prefix. In other words,
the routes with the lowest priorities.
When a route with a better priority is detected (possibly with a different
nexthop), we should uninstall the labels from the "old" routes and try
to install a new label for the new route (if there's one available in
the LIB).
In this specific case, ldpd was failing to uninstall the labels from the
old routes because it wasn't keeping track of each route's priority in
lde. With this missing bit of information, the parent process had no way
to get the correct label to uninstall when processing a IMSG_KLABEL_DELETE
message.
|
|
The Configuration Sequence Number optional TLV is documented in RFC 5036,
pages 53 and 54.
Fixes IxANVL LDP test 23.10.
|
|
This prevents neighbors stuck in the initialization FSM to linger forever
as long as the associated transport connection is up.
This timeout can be seen in the 'Session Initialization State Transition
Diagram' of RFC 5036. The RFC, however, doesn't specify how much we
should wait. Let's use 180 seconds for that, the default LDP hold time.
Fixes IxANVL LDP test 6.15.
|
|
|
|
With the introduction of IPv6 support by RFC 7552, the handling of Hello
packets in ldpd became something incredibly complex. Neighbors can change
from single-stack LDP to dual-stack and vice-versa. They can change
their transport preference, their transport addresses (IPv4 and IPv6)
and even start or stop sending the Dual-Stack TLV. We also have to take
care to reject things like multiple adjacencies advertising different
transport-addresses for the same neighbor. ldpd was failing for some of
the cases mentioned above, this patch fixes these issues and attempts
to make the code easier to read.
|
|
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.
|
|
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.
|
|
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()).
|
|
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.
|
|
|
|
|
|
For each child process (lde and ldpe), re-exec ldpd 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@
Requested by deraadt@
|
|
|
