| Age | Commit message (Collapse) | Author |
|---|
|
TAILQ_FOREACH().
No intentional functional change.
ok reyk@
|
|
modern TAILQ_FOREACH_SAFE().
No intentional functional change.
ok millert@ bluhm@ gilles@
|
|
with more modern TAILQ_FOREACH(). This what symget() was already
doing.
Add paranoia '{}' around body of symget()'s TAILQ_FOREACH().
No intentional functional change.
ok bluhm@ otto@
|
|
|
|
* Respect the session's negotiated maximum pdu length and split the
sending of our local addresses into multiple messages if necessary;
* Log sent/received addresses;
* Add new wrappers to send only one address (send_address_single)
and to send all addresses of the given address-family
(send_address_all). These wrappers create a temporary list of addresses
to be sent, and send_address() then acts on this last.
|
|
|
|
Remove these leftovers from the pre-fork+exec era.
Spotted by and ok rzalamena@ ok claudio@
|
|
* Standardize the logging format of sent and received messages:
"msg-[in|out]: message type: lsr-id A.B.C.D [additional info]";
* Log sent label messages as well, not only the received ones;
* Move the logging of sent notification messages from
send_notification_nbr() to send_notification_full(), this way notification
triggered by the lde process are logged as well;
* Minor clean-up.
|
|
If a neighbor was a nexthop for a given set of prefixes but it's not
anymore, then we should uninstall the associated label mappings (if any)
from the kernel. The same applies for the other way round (neighbor
wasn't a nexthop for a given set of prefixes but now is).
This issue is only evident when we have multiple links between a pair
of LSRs. Generally, when a link is shut down, the whole LDP is torn down
and all label mappings uninstalled automatically.
ok claudio@
|
|
On shutdown, there's no need to use kill(2) to kill the child
processes. Just closing the IPC sockets will make the children receive
an EOF, break out from the event loop and then exit.
Tha advantages of this "pipe teardown" are:
* simpler code;
* no need to pledge "proc" in the parent process;
* removal of a (hard to trigger) PID reuse race condition.
ok claudio@
|
|
Since recently the child processes call exec() after fork(), so they should
stop using _exit(2) and use exit(3) instead when shutting down.
Ok claudio@
|
|
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.
|
