summaryrefslogtreecommitdiff
path: root/src/libsystemd-network/lldp-tlv.c
AgeCommit message (Collapse)Author
2016-02-21sd-lldp: rework sd-lldp APILennart Poettering
This reworks the sd-lldp substantially, simplifying things on one hand, and extending the logic a bit on the other. Specifically: - Besides the sd_lldp object only one other object is maintained now, sd_lldp_neighbor. It's used both as storage for literal LLDP packets, and for maintainging info about peers in the database. Separation between packet, TLV and chassis data is not maintained anymore. This should be a major simplification. - The sd-lldp API has been extended so that a couple of per-neighbor fields may be queried directly, without iterating through the object. Other fields that may appear multiple times, OTOH have to be iterated through. - The maximum number of entries in the neighbor database is now configurable during runtime. - The generation of callbacks from sd_lldp objects is more restricted: callbacks are only invoked when actual data changed. - The TTL information is now hooked with a timer event, so that removals from the neighbor database due to TTLs now result in a callback event. - Querying LLDP neighbor database will now return a strictly ordered array, to guarantee stability. - A "capabilities" mask may now be configured, that selects what type of LLDP neighbor data is collected. This may be used to restrict collection of LLDP info about routers instead of all neighbors. This is now exposed via networkd's LLDP= setting. - sd-lldp's API to serialize the collected data to text files has been removed. Instead, there's now an API to extract the raw binary data from LLDP neighbor objects, as well as one to convert this raw binary data back to an LLDP neighbor object. networkd will save this raw binary data to /run now, and the client side can simply parse the information. - support for parsing the more exotic TLVs has been removed, since we are not using that. Instead there are now APIs to extract the raw data from TLVs. Given how easy it is to parse the TLVs clients should do so now directly instead of relying on our APIs for that. - A lot of the APIs that parse out LLDP strings have been simplified so that they actually return strings, instead of char arrays with a length. To deal with possibly dangerous characters the strings are escaped if needed. - APIs to extract and format the chassis and port IDs as strings has been added. - lldp.h has been simplified a lot. The enums are anonymous now, since they were never used as enums, but simply as constants. Most definitions we don't actually use ourselves have eben removed.
2016-02-10tree-wide: remove Emacs lines from all filesDaniel Mack
This should be handled fine now by .dir-locals.el, so need to carry that stuff in every file.
2015-11-16tree-wide: sort includesThomas Hindoe Paaboel Andersen
Sort the includes accoding to the new coding style.
2015-11-10Merge pull request #1735 from thom311/masterTom Gundersen
lldp: avoid compiler warnings in lldp_tfl_package_read* functions
2015-11-06doc: correct orthography, word forms and missing/extraneous wordsJan Engelhardt
2015-10-31lldp: avoid compiler warnings in lldp_tfl_package_read* functionsThomas Haller
gcc 5.1.1 wrongly warns about uninitialized variable @r2 when compiling with "-Og". Refactor the code to avoid the warnings. Fixes: 564cabd46c7c1532ad4d562bf8332eaed49ac201
2015-10-27util-lib: split out allocation calls into alloc-util.[ch]Lennart Poettering
2015-10-02lldp: fix parsing of TLV lengthBeniamino Galvani
tlv_packet_read_bytes() and tlv_packet_read_string() returned the wrong length when called after other functions which modify the offset in the container. In other words, if the TLV data length is X and we do a tlv_packet_read_u8(), a subsequent tlv_packet_read_bytes() should return a length of (X - 1).
2015-10-02lldp: check return value of lldp_tlv_packet_exit_container()Beniamino Galvani
2015-10-02lldp: add support for organizationally specific TLVsBeniamino Galvani
LLDP TLVs of type 127 are used to carry organizationally specific information and include additional fields to specify the OUI and subtype. Add support for parsing such fields and functions to access the most common IEEE 802.1 specific TLVs.
2015-10-02lldp: factor out common code in lldp-tlv.cBeniamino Galvani
2015-10-02lldp: add sd_lldp_tlv_packet_get_destination_type()Beniamino Galvani
It can be useful to know the destination address of a LLDP frame because it determines the scope of propagation of the frame and thus this information be used to know whether the neighbor is connected to the same physical link. See clause 7.1 of IEEE Std 802.1AB-2009.
2015-10-02lldp: move TLV related functions to lldp-tlv.cBeniamino Galvani
Move some public functions from lldp-internal.c to lldp-tlv.c, as now they are not internal functions anymore.
2015-10-02lldp: export opaque TLV type and accessor functionsBeniamino Galvani
Export struct tlv_packet as a public opaque sd_lldp_packet type and make its accessor functions public.
2015-10-02lldp: add reference counter to struct tlv_packetBeniamino Galvani
Add a reference counter to the tlv_packet structure so that it can be shared between multiple users and properly free'd when no longer in use.
2015-06-08tree-wide: remove spurious spaceThomas Hindoe Paaboel Andersen
2015-03-27fix gcc warnings about uninitialized variablesHarald Hoyer
like: src/shared/install.c: In function ‘unit_file_lookup_state’: src/shared/install.c:1861:16: warning: ‘r’ may be used uninitialized in this function [-Wmaybe-uninitialized] return r < 0 ? r : state; ^ src/shared/install.c:1796:13: note: ‘r’ was declared here int r; ^
2014-12-19networkd: Introduce Link Layer Discovery Protocol (LLDP)Susant Sahani
This patch introduces LLDP support to networkd. it implements the receiver side of the protocol. The Link Layer Discovery Protocol (LLDP) is an industry-standard, vendor-neutral method to allow networked devices to advertise capabilities, identity, and other information onto a LAN. The Layer 2 protocol, detailed in IEEE 802.1AB-2005.LLDP allows network devices that operate at the lower layers of a protocol stack (such as Layer 2 bridges and switches) to learn some of the capabilities and characteristics of LAN devices available to higher layer protocols.