GithubHelp home page GithubHelp logo

lldpd / lldpd Goto Github PK

View Code? Open in Web Editor NEW
577.0 577.0 174.0 7.88 MB

implementation of IEEE 802.1ab (LLDP)

Home Page: https://lldpd.github.io

License: Other

Shell 0.84% C 83.45% Python 7.42% Ruby 0.16% HTML 0.08% Awk 0.04% Makefile 0.89% M4 4.32% Roff 2.58% Nix 0.16% Dockerfile 0.05% Emacs Lisp 0.01%
cdp discovery lldp lldpd network

lldpd's Introduction

lldpd: implementation of IEEE 802.1ab (LLDP)

Build Status

https://lldpd.github.io/

Features

LLDP (Link Layer Discovery Protocol) is an industry standard protocol designed to supplant proprietary Link-Layer protocols such as Extreme's EDP (Extreme Discovery Protocol) and CDP (Cisco Discovery Protocol). The goal of LLDP is to provide an inter-vendor compatible mechanism to deliver Link-Layer notifications to adjacent network devices.

lldpd implements both reception and sending. It also implements an SNMP subagent for net-snmp to get local and remote LLDP information. The LLDP-MIB is partially implemented but the most useful tables are here. lldpd also partially implements LLDP-MED.

lldpd supports bridge, vlan and bonding.

The following OS are supported:

  • FreeBSD
  • GNU/Linux
  • macOS
  • NetBSD
  • OpenBSD
  • Solaris

Windows is not supported but you can use WinLLDPService as a transmit-only agent.

Installation

For general instructions prefer the website, including building from released tarballs.

To compile lldpd from Git, use the following commands:

./autogen.sh
./configure
make
sudo make install

lldpd uses privilege separation to increase its security. Two processes, one running as root and doing minimal stuff and the other running as an unprivileged user into a chroot doing most of the stuff, are cooperating. You need to create a user called _lldpd in a group _lldpd (this can be change with ./configure). You also need to create an empty directory /usr/local/var/run/lldpd (it needs to be owned by root, not _lldpd!). If you get fuzzy timestamps from syslog, copy /etc/locatime into the chroot.

lldpcli lets one query information collected through the command line. If you don't want to run it as root, just install it setuid or setgid _lldpd.

Installation (Docker)

You can use Docker to run lldpd:

docker run --rm --net=host --uts=host \
           -v /etc/os-release:/etc/os-release \
           --cap-add=NET_RAW --cap-add=NET_ADMIN \
           --name lldpd \
           ghcr.io/lldpd/lldpd:latest

In place of latest which provides you with the latest stable version, you may use 1, 1.0, 1.0.12 to match specific versions, or master to get the development version.

To execute lldpcli, use:

docker exec lldpd lldpcli show neighbors

Or to get the command-line:

docker exec -it lldpd lldpcli

Installation (macOS)

The same procedure as above applies for macOS. However, there are simpler alternatives:

  1. Use Homebrew:

    brew install lldpd
    # Or, for the latest version:
    brew install https://raw.github.com/lldpd/lldpd/master/osx/lldpd.rb
    
  2. Build an OS X installer package which should work on the same version of OS X (it is important to use a separate build directory):

    mkdir build && cd build
    ../configure --prefix=/usr/local --localstatedir=/var --sysconfdir=/private/etc --with-embedded-libevent \
        --without-snmp
    make -C osx pkg
    

    If you want to compile for an older version of macOS, you need commands like those:

    mkdir build && cd build
    ../configure --prefix=/usr/local --localstatedir=/var --sysconfdir=/private/etc --with-embedded-libevent \
       --without-snmp \
       CFLAGS="-mmacosx-version-min=11.1" \
       LDFLAGS="-mmacosx-version-min=11.1"
    make -C osx pkg
    

    You can check with otool -l that you got what you expected in term of supported versions. If you are running on ARM64, you can configure a binary supporting both architectures by adding ARCHS="arm64 x86_64" to the arguments of the make command.

If you don't follow the above procedures, you will have to create the user/group _lldpd. Have a look at how this is done in osx/scripts/postinstall.

Installation (Android)

  1. Don't clone the repo or download the master branch from GitHub. Instead, download the official release from the website https://lldpd.github.io/. Unpack into a working directory.

  2. Download the Android NDK (version 22 or later). Unpack into a working directory next to the lldpd directory.

  3. Install automake, libtool, and pkg-config. (sudo apt-get install automake libtool pkg-config)

  4. In the root of the lldpd directory, make a compile.sh file containing this script:

export TOOLCHAIN=$PWD/android-ndk/toolchains/llvm/prebuilt/linux-x86_64
export TARGET=armv7a-linux-androideabi
export API=30
# DO NOT TOUCH BELOW
export AR=$TOOLCHAIN/bin/llvm-ar
export CC=$TOOLCHAIN/bin/$TARGET$API-clang
export CXX=$TOOLCHAIN/bin/$TARGET$API-clang++
export LD=$TOOLCHAIN/bin/ld
export RANLIB=$TOOLCHAIN/bin/llvm-ranlib
export STRIP=$TOOLCHAIN/bin/llvm-strip
export AS=$CC
./autogen.sh
mkdir -p build && cd build
../configure \
    --host=$TARGET \
    --with-sysroot=$TOOLCHAIN/sysroot \
    --prefix=/system \
    --sbindir=/system/bin \
    --runstatedir=/data/data/lldpd \
    --with-privsep-user=root \
    --with-privsep-group=root \
    PKG_CONFIG=/bin/false
make
make install DESTDIR=$PWD/install
  1. In the Android NDK directory, locate the toolchains/llvm/prebuilt/linux-x86_64 directory and change the TOOLCHAIN variable of the above script to match the path where the linux-x86_64 directory resides.
export TOOLCHAIN=$PWD/android-ndk-r22b-linux-x86_64/android-ndk-r22b/toolchains/llvm/prebuilt/linux-x86_64
  1. Determine the CPU architecture target (adb shell getprop ro.product.cpu.abi). Change the TARGET variable in the above script to match the target architecture. The target name will not exactly match the output of the adb command as there will be a trailing suffix to the target name, so look in the linux-x86_64/bin directory for the clang file that starts with the CPU architecture target. Don't include the API version in the target name.
$ adb shell getprop ro.product.cpu.abi
armeabi-v7a
linux-x86_64/bin$ ls *-clang
aarch64-linux-android21-clang     armv7a-linux-androideabi23-clang  i686-linux-android26-clang
aarch64-linux-android22-clang     armv7a-linux-androideabi24-clang  i686-linux-android27-clang
aarch64-linux-android23-clang     armv7a-linux-androideabi26-clang  i686-linux-android28-clang
aarch64-linux-android24-clang     armv7a-linux-androideabi27-clang  i686-linux-android29-clang
aarch64-linux-android26-clang     armv7a-linux-androideabi28-clang  i686-linux-android30-clang
aarch64-linux-android27-clang     armv7a-linux-androideabi29-clang  x86_64-linux-android21-clang
aarch64-linux-android28-clang     armv7a-linux-androideabi30-clang  x86_64-linux-android22-clang
aarch64-linux-android29-clang     i686-linux-android16-clang        x86_64-linux-android23-clang
aarch64-linux-android30-clang     i686-linux-android17-clang        x86_64-linux-android24-clang
armv7a-linux-androideabi16-clang  i686-linux-android18-clang        x86_64-linux-android26-clang
armv7a-linux-androideabi17-clang  i686-linux-android19-clang        x86_64-linux-android27-clang
armv7a-linux-androideabi18-clang  i686-linux-android21-clang        x86_64-linux-android28-clang
armv7a-linux-androideabi19-clang  i686-linux-android22-clang        x86_64-linux-android29-clang
armv7a-linux-androideabi21-clang  i686-linux-android23-clang        x86_64-linux-android30-clang
armv7a-linux-androideabi22-clang  i686-linux-android24-clang
export TARGET=armv7a-linux-androideabi
  1. Set the API variable in the script above to your target API version. Check in the same linux-x86_64/bin to ensure the API you are targeting has a supported clang file for that CPU architecture and version. As of this writing, there is support for API 21-30 included for all architectures and some CPU architectures supported back to version 16.
export API=30
  1. Run the compile script (./compile.sh).

  2. Copy the ./bin/* and ./lib/*.so files from lldpd/build/install/system to the target system (./bin/* to /system/bin, ./lib/*.so to /system/lib64):

# Push files to target
cd build/install/system
adb shell mkdir -p /sdcard/Download/lldpd/bin
adb push bin/lldpcli /sdcard/Download/lldpd/bin/lldpcli
adb push bin/lldpd /sdcard/Download/lldpd/bin/lldpd
adb shell mkdir -p /sdcard/Download/lldpd/lib64
adb push lib/liblldpctl.so /sdcard/Download/lldpd/lib64/liblldpctl.so

# Enter target shell and move files
adb shell
# Run as root for all commands
$ su
# Make /system writeable
$ mount -o rw,remount /system
$ mv /sdcard/Download/lldpd/bin/lldpcli /system/bin/lldpcli
$ chmod 755 /system/bin/lldpcli
$ chown root:shell /system/bin/lldpcli
$ mv /sdcard/Download/lldpd/bin/lldpd /system/bin/lldpd
$ chmod 755 /system/bin/lldpd
$ chown root:shell /system/bin/lldpd
# $ touch /system/bin/lldpctl
# $ chmod 755 /system/bin/lldpctl
# $ chown root:shell /system/bin/lldpctl
$ mv /sdcard/Download/lldpd/lib64/liblldpctl.so /system/lib64/liblldpctl.so
$ chmod 644 /system/lib64/liblldpctl.so
$ chown root:root /system/lib64/liblldpctl.so
# Make /system readonly again
$ mount -o ro,remount /system
# Might not be necessary on some systems
$ mkdir /data/data/lldpd
$ chmod 700 /data/data/lldpd
$ chown shell:shell /data/data/lldpd
# Clean up
$ rm -rf /sdcard/Download/lldpd

Usage

lldpd also implements CDP (Cisco Discovery Protocol), FDP (Foundry Discovery Protocol), SONMP (Nortel Discovery Protocol) and EDP (Extreme Discovery Protocol). However, recent versions of IOS should support LLDP and most Extreme stuff support LLDP. When a EDP, CDP or SONMP frame is received on a given interface, lldpd starts sending EDP, CDP, FDP or SONMP frame on this interface. Informations collected through EDP/CDP/FDP/SONMP are integrated with other informations and can be queried with lldpcli or through SNMP.

More information:

Compatibility with older kernels

If you have a kernel older than Linux 4.0, you need to compile lldpd with --enable-oldies to enable some compatibility functions: otherwise, lldpd will only rely on Netlink to receive wireless, bridge, bond and VLAN information.

For bonding, you need 2.6.24 (in previous version, PACKET_ORIGDEV affected only non multicast packets). See:

Otherwise, a packet received on a bond will be affected to all interfaces of the bond. In this case, lldpd will affect a received randomly to one of the interface (so a neighbor may be affected to the wrong interface).

On 2.6.27, we are able to receive packets on real interface for enslaved devices. This allows one to get neighbor information on active/backup bonds. Without the 2.6.27, lldpd won't receive any information on inactive slaves. Here are the patchs (thanks to Joe Eykholt):

On FreeBSD, only a recent 9 kernel (9.1 or more recent) will allow to send LLDP frames on enslaved devices. See this bug report for more information:

Some devices (notably Cisco IOS) send frames tagged with the native VLAN while they should send them untagged. If your network card does not support accelerated VLAN, you will receive those frames as long as the corresponding interface exists (see below). However, if your network card handles VLAN encapsulation/decapsulation (check with ethtool -k), you need a recent kernel to be able to receive those frames without listening on all available VLAN. Starting from Linux 2.6.27, lldpd is able to capture VLAN frames when VLAN acceleration is supported by the network card. Here is the patch:

On some other versions, frames are sent on VLAN 1. If this is not the native VLAN and if your network card support accelerated VLAN, you need to subscribe to this VLAN as well. The Linux kernel does not provide any interface for this. The easiest way is to create the VLAN for each port:

ip link add link eth0 name eth0.1 type vlan id 1
ip link set up dev eth0.1

You can check both cases using tcpdump:

tcpdump -epni eth0 ether host 01:80:c2:00:00:0e
tcpdump -eni eth0 ether host 01:80:c2:00:00:0e

If the first command does not display received LLDP packets but the second one does, LLDP packets are likely encapsulated into a VLAN:

10:54:06.431154 f0:29:29:1d:7c:01 > 01:80:c2:00:00:0e, ethertype 802.1Q (0x8100), length 363: vlan 1, p 7, ethertype LLDP, LLDP, name SW-APP-D07.VTY, length 345

In this case, just create VLAN 1 will fix the situation. There are other solutions:

  1. Disable VLAN acceleration on the receive side (ethtool -K eth0 rxvlan off) but this may or may not work. Check if there are similar properties that could apply with ethtool -k eth0.
  2. Put the interface in promiscuous mode with ip link set promisc on dev eth0.

The last solution can be done directly by lldpd (on Linux only) by using the option configure system interface promiscuous.

On modern networks, the performance impact should be nonexistent.

Development

During development, you may want to execute lldpd at its current location instead of doing make install. The correct way to do this is to issue the following command:

sudo libtool execute src/daemon/lldpd -L $PWD/src/client/lldpcli -d

You can append any further arguments. If lldpd is unable to find lldpcli it will start in an unconfigured mode and won't send or accept LLDP frames.

There is a general test suite with make check. It's also possible to run integration tests. They need pytest and rely on Linux containers to be executed.

To enable code coverage, use:

../configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var \
             --enable-sanitizers --enable-gcov --with-snmp \
             CFLAGS="-O0 -g"
make
make check
# maybe, run integration tests
lcov --base-directory $PWD/src/lib \
     --directory src --capture --output-file gcov.info
genhtml gcov.info --output-directory coverage

Fuzzing

Using address sanitizer:

export CC=clang
export CFLAGS="-O1 -fno-omit-frame-pointer -gline-tables-only -fsanitize=address -fsanitize-address-use-after-scope -fsanitize=fuzzer-no-link"
export LIB_FUZZING_ENGINE="-fsanitize=fuzzer"

Using undefined-behaviour sanitizer:

export CC=clang
export CFLAGS="-O1 -fno-omit-frame-pointer -gline-tables-only -fsanitize=array-bounds,bool,builtin,enum,float-divide-by-zero,function,integer-divide-by-zero,null,object-size,return,returns-nonnull-attribute,shift,signed-integer-overflow,unsigned-integer-overflow,unreachable,vla-bound,vptr -fno-sanitize-recover=array-bounds,bool,builtin,enum,float-divide-by-zero,function,integer-divide-by-zero,null,object-size,return,returns-nonnull-attribute,shift,signed-integer-overflow,unreachable,vla-bound,vptr -fsanitize=fuzzer-no-link"
export LIB_FUZZING_ENGINE="-fsanitize=fuzzer"

Using memory sanitizer:

export CC=clang
export CFLAGS="-O1 -fno-omit-frame-pointer -gline-tables-only -fsanitize=memory -fsanitize-memory-track-origins -fsanitize=fuzzer-no-link"
export LIB_FUZZING_ENGINE="-fsanitize=fuzzer"

Build and run:

./configure --disable-shared --enable-pie --enable-fuzzer=$LIB_FUZZING_ENGINE
make
cd tests/
./fuzz_cdp   fuzzing_seed_corpus/fuzz_cdp_seed_corpus
./fuzz_edp   fuzzing_seed_corpus/fuzz_edp_seed_corpus
./fuzz_lldp  fuzzing_seed_corpus/fuzz_lldp_seed_corpus
./fuzz_sonmp fuzzing_seed_corpus/fuzz_sonmp_seed_corpus

With AFL++

You can use AFL++ to test some other aspects of lldpd. To test frame decoding:

export CC=afl-clang-fast
./configure --disable-shared --enable-pie
make clean check
cd tests
mkdir inputs
mv *.pcap inputs
afl-fuzz -i inputs -o outputs ./decode @@

Embedding

To embed lldpd into an existing system, there are two point of entries:

  1. If your system does not use standard Linux interface, you can support additional interfaces by implementing the appropriate struct lldpd_ops. You can look at src/daemon/interfaces-linux.c for examples. Also, have a look at interfaces_update() which is responsible for discovering and registering interfaces.

  2. lldpcli provides a convenient way to query lldpd. It also comes with various outputs, including XML which allows one to parse its output for integration and automation purpose. Another way is to use SNMP support. A third way is to write your own controller using liblldpctl.so. Its API is described in src/lib/lldpctl.h. The custom binary protocol between liblldpctl.so and lldpd is not stable. Therefore, the library should always be shipped with lldpd. On the other hand, programs using liblldpctl.so can rely on the classic ABI rules.

Troubleshooting

You can use tcpdump to look after the packets received and send by lldpd. To look after LLDPU, use:

tcpdump -s0 -vv -pni eth0 ether dst 01:80:c2:00:00:0e

Intel X710 cards may handle LLDP themselves, intercepting any incoming packets. If you don't see anything through tcpdump, check if you have such a card (with lspci) and stop the embedded LLDP daemon:

for f in /sys/kernel/debug/i40e/*/command; do
    echo lldp stop > $f
done

This may also apply to the ice (Intel E8xx cards) driver. These steps are not necessary with a recent version of lldpd (1.0.11+).

License

lldpd is distributed under the ISC license:

Permission to use, copy, modify, and/or distribute this software for any purpose with or without fee is hereby granted, provided that the above copyright notice and this permission notice appear in all copies.

THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.

Also, lldpcli will be linked to GNU Readline (which is GPL licensed) if available. To avoid this, use --without-readline as a configure option.

lldpd's People

Contributors

alagoutte avatar andihofmeister avatar apconole avatar chutz avatar commodo avatar dependabot[bot] avatar gsauthof avatar harshalgohel avatar jonasj76 avatar jp-t avatar jpoliv avatar kcgthb avatar kghost avatar lajson avatar matsimon avatar mobbitster avatar mtremer avatar nmeum avatar nsccap avatar ordex avatar pavel-shirshov avatar radhikamahankali avatar roopa-prabhu avatar steven-webster avatar systemcrash avatar tannhaeuser avatar theauthority avatar vincentbernat avatar waldyrious avatar wataash avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

lldpd's Issues

init script doesn't restart lldpd on package upgrade?

rpm -q --scripts lldpd
...
postuninstall scriptlet (using /bin/sh):
if [ "$1" -ge "1" ]; then
/sbin/service lldpd >/dev/null 2>&1 || :
fi

should be:

/sbin/service lldpd condrestart >/dev/null 2>&1 || :

to restart the service.

in the spec file its...

%postun
if [ "$1" -ge "1" ]; then
/sbin/service lldpd >/dev/null 2>&1 || :
fi

i could fork and send a pull request? but its a one liner

rhel/centos5 rpm dependencies

When installing the 0.7.5 package during a kickstart I get the following error condition.

warning: lldpd-0.7.5-1.1: Header V3 DSA signature: NOKEY, key ID 72e0a4f6
error: %pre(lldpd-0.7.5-1.1.x86_64) scriptlet failed, exit status 1

error: install: %pre scriptlet failed (2), skipping lldpd-0.7.5-1.1

Because of the error in the pre script it doesn't install.
Here is the patch that I used to fix the issue:

*** /users/lbrigman/rpmbuild/SPECS/lldpd.spec 2013-06-22 05:19:54.000000000 -0700
--- /users/lbrigman/lldpd.spec.new 2013-06-28 09:16:26.133075000 -0700


*** 29,35 ****
Summary: Implementation of IEEE 802.1ab (LLDP)
Name: lldpd
Version: 0.7.5
! Release: 1.1
License: MIT
Group: System Environment/Daemons
URL: http://vincentbernat.github.com/lldpd/
--- 29,35 ----
Summary: Implementation of IEEE 802.1ab (LLDP)
Name: lldpd
Version: 0.7.5
! Release: 1.2
License: MIT
Group: System Environment/Daemons
URL: http://vincentbernat.github.com/lldpd/
*************** BuildRequires: libxml2-devel
*** 50,55 ****
--- 50,56 ----
%if 0%{?suse_version}
PreReq: %fillup_prereq %insserv_prereq pwdutils
%else

  • PreReq: /usr/sbin/groupadd /usr/sbin/useradd
    Requires(post): chkconfig
    Requires(preun): chkconfig
    Requires(preun): initscripts

Support of shutdown LLDPDU

Currently, shutdown LLDPDU is flagged as invalid because there is no TTL TLV. It should be accepted and the corresponding entry should be removed.

debian squeeze package from build service doesn't install

cat /etc/debian_version
6.0.7

md5sum /tmp/lldpd_0.7.1-0_amd64.deb
9f0d771005ddc83b66c44bca810bb103 /tmp/lldpd_0.7.1-0_amd64.deb

dpkg -i /tmp/lldpd_0.7.1-0_amd64.deb
(Reading database ... 53697 files and directories currently installed.)
Preparing to replace lldpd 0.7.1-0 (using /tmp/lldpd_0.7.1-0_amd64.deb) ...
Unpacking replacement lldpd ...
dpkg: dependency problems prevent configuration of lldpd:
lldpd depends on upstart-job; however:
Package upstart-job is not installed.
dpkg: error processing lldpd (--install):
dependency problems - leaving unconfigured
Processing triggers for man-db ...
Errors were encountered while processing:
lldpd

I've tried to find where it's getting upstart-job from but I'm lost in the maze of debian packaging.

Building lldpd for ARM with 2009-Codesourcery toolchain

Hi Vincent:
I am a newbie and I am having multiple issues building and running lldpd for our ARM platform with 2009-q3 codesourcery toolchain.
First off - I downloaded the 1.5.0 version of tar file and ran into the segmentation fault issue as reported in some other ticket. I resolved that with the ac_cv_cflags_gcc_option__fstack_protector=no option as suggested.
But even if I get past that issue - If I run the daemon from our platform, I see this:

./lldpd -c -dd &
root@tci6614-evm:~# lldpd_main()
getting timezone info
getting os rel info
lldpd_get_os_release: could not open /etc/os-release: No such file or directory
priv_ping: monitor ready
lldpd_main: protocol LLDP enabled
lldpd_main: protocol CDPv1 enabled
lldpd_main: protocol CDPv2 enabled
lldpd_main: protocol SONMP disabled
lldpd_main: protocol EDP disabled
lldpd_main: protocol FDP disabled

[1] + Segmentation fault ./lldpd -c -dd

After this, if I do ps aux, I do see:
_lldpd 1430 0.0 0.0 2120 288 ttyS0 S 02:35 0:00 ./lldpd -c -dd

The only thing that I have done so far is to add _lldpd user and created the /var/run/lldpd directory.

Any pointers/ideas?

coordinate subtype resolution values not set correctly

The resolution values (loRes, laRes, altRes) as described in TIA (wich refers DHCP Option for Coordinate LCI, RFC 3825) as " (LaRes: Latitude) resolution. 6 bits indicating the number of valid bits in the fixed-point value of (Latitude)." in lldpd are set statically to 6 (LoRes, LaRes) or 2 (AltRes).

Reason might be the below cited code:

//call for latitude and longitude                        v
write_fixed_precision((uint8_t*)mloc->location->data, l, 6, 9, 25);
//call for altitude                                           v
write_fixed_precision((uint8_t*)mloc->location->data + 11, l, 2, 22, 8);

--version function

I would like to request a lldpctl --version function and lldpd --version function. Both or which would show the version of the software.

lldpcli-watch reports interface changes late

I am studying with LLDP protocol. And I played with your wonderful implementation.
But I had some problem with lldpcli - watch features. It reported interfaces changes later. Since I can use show neighbors to find the interface has changes correctly. Why [watch] couldn't reported quickly. The delay is underestimated. Sometimes the watch reported with old information that happened more than 10 mins ago. I am not sure if you can duplicate the issue at your side easily. Thanks!

James

Unaligned access when demarshaling on the ARM...

Several processors require aligned accesses on certain data types, like structures, unless told otherwise.

It turns out there is an alignment issue here and several places like it. The problem stems from buffer being casted to a struct marshal_serialized pointer near the top of the buffer:

/* Unserialize the given object. */
size_t
marshal_unserialize_(struct marshal_info *mi, void *buffer, size_t len, void **output,
    void *_pointers, int skip, int osize)
{
    int    total_len = sizeof(struct marshal_serialized) + (skip?0:mi->size);
    struct marshal_serialized *serialized = buffer;
    struct gc_l *pointers = _pointers;
    int size, already, extra = 0;
    void *new;
    struct marshal_subinfo *current;
    struct gc *apointer;

buffer is the input buffer being read from. Because of previous data, buffer may not be aligned on the proper boundary. As a result, any call that accesses serialized later causes an alignment trap, such as line 290 of marshal.c:

    if (!skip) {
        if ((*output = marshal_alloc(pointers, size + extra, serialized->orig)) == NULL) {
            log_warnx("marshal", "unable to allocate memory to unserialize structure %s",
                mi->name);
            total_len = 0;
            goto unmarshal_error;
        }
        memcpy(*output, serialized->object, size);
    }

serialized->orig is what causes the trap. Flagging struct marshal_serialized as packed fixes the issue, though it may not be adequate for your needs:

/* A serialized object */
struct marshal_serialized {
    void         *orig; /* Original reference. Also enforce alignment. */
    size_t        size;
    unsigned char object[0];
} __attribute__((packed));

lldpd and friends seem to work correctly after making this change, though we still have more testing to do.

Mac Uninstall

Hi there,
I installed the Mac OS X package that you have on your website. As soon as I finished the install the wireless card and my usb ethernet on my Mac Book Air stopped functioning. If I disable the daemon my wireless starts to work again but not my usb Ethernet. Is there a way to fix this or uninstall this package? Thank you for your help!
Jordan

Does not compile without lldpmed

Version:

0.6.1

Used configure:

./configure --disable-lldpmed

Error shown in make:

make[2]: Entering directory `/home/q276704/LLDP/lldpd-0.6.1/src/lib'
  CC     errors.lo
  CC     connection.lo
  CC     atom.lo
  CC     atom-private.lo
atom-private.c: In function '_lldpctl_atom_get_int_config':
atom-private.c:353: error: 'struct lldpd_config' has no member named 'c_noinventory'
atom-private.c: At top level:
atom-private.c:2507: warning: missing initializer
atom-private.c:2507: warning: (near initialization for 'builders[14].size')
make[2]: *** [atom-private.lo] Error 1
make[2]: Leaving directory `/home/q276704/LLDP/lldpd-0.6.1/src/lib'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/q276704/LLDP/lldpd-0.6.1'
make: *** [all] Error 2

Cause:

One Switch-statement within _lldpctl_atom_get_int_config is not escaped by ifdef:

case lldpctl_k_config_lldpmed_noinventory:
        return c->config->c_noinventory;

Patch-suggestion:

Diff:
$ diff lldpd-0.6.1/src/lib/atom-private.c lldpd-0.6.1-patched/src/lib/atom-private.c
351a352
>       #ifdef ENABLE_LLDPMED
353a355
>       #endif

Looking like:

#ifdef ENABLE_LLDPMED
case lldpctl_k_config_lldpmed_noinventory:
        return c->config->c_noinventory;
#endif

Tested: it compiles and runs without visible implications.

rhel/centos5 rpm dependencies

When installing the 0.7.5 package during a kickstart I get the following error condition.

warning: lldpd-0.7.5-1.1: Header V3 DSA signature: NOKEY, key ID 72e0a4f6
error: %pre(lldpd-0.7.5-1.1.x86_64) scriptlet failed, exit status 1

error: install: %pre scriptlet failed (2), skipping lldpd-0.7.5-1.1

Because of the error in the pre script it doesn't install.
Here is the patch that I used to fix the issue:

*** /users/lbrigman/rpmbuild/SPECS/lldpd.spec 2013-06-22 05:19:54.000000000 -0700
--- /users/lbrigman/lldpd.spec.new 2013-06-28 09:16:26.133075000 -0700


*** 29,35 ****
Summary: Implementation of IEEE 802.1ab (LLDP)
Name: lldpd
Version: 0.7.5
! Release: 1.1
License: MIT
Group: System Environment/Daemons
URL: http://vincentbernat.github.com/lldpd/
--- 29,35 ----
Summary: Implementation of IEEE 802.1ab (LLDP)
Name: lldpd
Version: 0.7.5
! Release: 1.2
License: MIT
Group: System Environment/Daemons
URL: http://vincentbernat.github.com/lldpd/
*************** BuildRequires: libxml2-devel
*** 50,55 ****
--- 50,56 ----
%if 0%{?suse_version}
PreReq: %fillup_prereq %insserv_prereq pwdutils
%else

  • PreReq: /usr/sbin/groupadd /usr/sbin/useradd
    Requires(post): chkconfig
    Requires(preun): chkconfig
    Requires(preun): initscripts

lldpctl -u fails

missing "u:" in getopt parameter causes

$ lldpcli -u /var/run/lldp.socket.s1
lldpcli: invalid option -- 'u'
lldpcli: invalid option -- 'u'
Usage:   lldpcli [OPTIONS ...] [COMMAND ...]
Version: lldpd 0.7.6

-d          Enable more debugging information.
-u          Specify the Unix-domain socket used for communication with lldpd(8).
-f format   Choose output format (plain, keyvalue or xml).
-c          Read the provided configuration file.

see manual page lldpcli(8) for more information

please add "u:" to here https://github.com/vincentbernat/lldpd/blob/master/src/client/lldpcli.c#L414

Null pointer access when lldpd is started with -k

If the following code fails:

lsb_release = lldpd_get_os_release();
if (!lsb_release) {
    lsb_release = lldpd_get_lsb_release();
}

then there is a null pointer access if lldpd is started with -k (advertise_version==0).
Fixed it by changing:
if (!(cfg->g_advertise_version = advertise_version))
into
if (lsb_release && !(cfg->g_advertise_version = advertise_version))

support for writing ifAlias

lldpd already sends ifAlias to peers, if it can find one. It would be extremely nice to do the inverse as well: to set ifAlias based on the peer. ladpd has such behavior, and it's a nice feature. (I am even considering writing snmp-set scripts to do this on the switches as well)

NetBSD DomU - lldpd can't get media information from xennet0

Hi, I'm trying to make a pkgsrc package of lldpd. It compiled and runs almost fine, except for:

2013-04-27T10:45:25 [WARN/interfaces] unable to get media information from xennet0: Inappropriate ioctl for device

I'm not sure how do you get media information in NetBSD. I thought plain ifconfig presents it, but mine shows only:

xennet0: flags=8863<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST> mtu 1500
capabilities=2800<TCP4CSUM_Tx,UDP4CSUM_Tx>
enabled=0
address: 00:16:3e:69:67:78
inet 5.134.79.8 netmask 0xffffffe0 broadcast 5.134.79.31
inet6 fe80::216:3eff:fe69:6778%xennet0 prefixlen 64 scopeid 0x1

Maybe you will get some hints here:
http://netbsd.gw.com/cgi-bin/man-cgi?ifmedia+4+NetBSD-current

Regards,

lldpcli read only

Hi,

I dont have a write right when I run lldpcli (as root).

# lldpcli
[lldpcli] $ configure
unknown command from argument 1: `configure`

My config :
Debian Wheezy (3.2.0)
lldpd installed by backports package (0.7.7)

Thanx for your work

lldpd on uclinux (linux 2.4)

Hi,

I'm trying to get lldpd and lldpdcli running on a uclinux platform. The main disadvantage of uclinux is the lack of an mmu and therefore fork is not possible. As the code uses fork I'm thinking of another solution.

vfork is possible but this does not seem to work properly with the current setup of the code (This is the documentation uclinux gives about fork/vfork: uClinux does not implement fork(); instead it implements vfork(). This does not mean no multitasking, it simply means that the parent blocks until the child does exec() or exit(). You can still get full multitasking.).

I'm trying to get both programs running in a separate init.d script, however this seems to fail. The lldpd daemon work if I remove the fork but than hangs on a must_read call in the priv.c priv_iface_init function.

The lldpcli starts-up, but will hang if any command is issues (after the connect).

Would it ever be possible to get this code runinng on such a platform with this construction? I do have some clues on how to proceed but would rather verify this with you.

Thanks for any help.

Configuration through a CLI and a configuration file

Currently, lldpd can be configured with some command line parameter. There is the beginning of configuration support in lldpctl (for LLDP-MED location). To be a complete LLDP implementation, we need more complete configuration. The administrator should be able to enable/disable each port independantly, like this is done on a switch.

To avoid to add a parser, the configuration will be done by lldpctl. When lldpd is started, it will wait to be configured by lldpctl. lldpctl will read and write the configuration from/to a file. A CLI could also be added.

This way, the memory footprint and the number of lines in lldpd will stay pretty low.

Android support?

I'm trying to build it for Android but not easy for me.
I need to negotiate 802.3at to enable 28W power.
Any suggestions?

:)
Thanks,
M

Segmentation faults when cross compiled for ARM 7 target

Hi,
Has anybody successfully built this package for an ARM target. I have managed to cross compile the source using the following tool chain:
arm-none-linux-gnueabi-gcc (Sourcery G++ Lite 2009q1-203) 4.3.3
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

However when I run the daemon on the target board it seg faults. After some poking around I traced it to the char array declaration of char opts[] = "H:vhkrdxX:m:4:6:I:C:p:M:P:S:i@ "; in the lldpd_main function in lldpd.c. If i make this declaration 'static' or I move it to have global scope, then it get passed this initial seg fault. It then fails else where but one thing at a time. So my question is, does this sound familiar to anyone?

Many Thanks,
Toz Ainsworth

LLDP-MED fast start support

LLDP-MED fast start is not yet supported. Currently, lldpd as a giant loop sleeping 30 seconds. It should evolve to a per-port/event driven scheduler.

Better debug logging

It is difficult to find the right balance for the debug level: too much information and we can't see what we need to and too little and we may miss important information. Currently, the debug level does not log that much.

Each debug log should be prefixed by some keyword and the logs should be filtered using this keyword. For example -D lldp would enable debug in the LLDP protocol. -D event would enable debug in the event subsystem. -D interface would enable debug when selecting an interface.

System Name TLV announcement

Hi,

I'm running lldpd like this :

/usr/sbin/lldpd -x -S -m

But when I run tcpdump on interface, I can see :

    System Name TLV (5), length 18: <HOSTNAME>
    System Description TLV (6), length 19
      <NAME>

The fact is that System Description is correctly define, but not System Name. Using -P does not change anything.

Is it something wanted/normal ?

logging timestamps not consistent

When the lldpd process is not in a change root the time stamps in the log match that of the local time.
Once the chroot occurs in the process the time stamps in the log revert to UTC.

Log output example:
Dec 1 18:20:32 sweng0096 lldpd[1187]: lldpd_main: protocol FDP disabled
Dec 1 18:20:54 sweng0096 lldpd[1187]: lldpd_shutdown: signal received, exiting
Dec 1 10:20:54 sweng0096 lldpd[1389]: lldpd_get_os_release: could not open /etc/os-release: No such file or directory
Dec 1 10:20:54 sweng0096 lldpd[1389]: lldpd_get_lsb_release: lsb_release information not available
Dec 1 10:20:54 sweng0096 lldpd[1393]: lldpd_main: protocol LLDP enabled
Dec 1 18:20:54 sweng0096 lldpd[1393]: lldpd_main: protocol CDPv1 disabled
Dec 1 18:20:54 sweng0096 lldpd[1393]: lldpd_main: protocol CDPv2 disabled
Dec 1 18:20:54 sweng0096 lldpd[1393]: lldpd_main: protocol SONMP disabled
Dec 1 18:20:54 sweng0096 lldpd[1393]: lldpd_main: protocol EDP disabled
Dec 1 18:20:54 sweng0096 lldpd[1393]: lldpd_main: protocol FDP disabled

Spurious warning when a bond is a member of a bridge

We see this consistently on hosts which have a bonded interface which is a member of a bridge. The pattern is typical for us on KVM servers.

The following message appears once every 10 minutes in the log:

Sep 14 20:59:35 xxxxxxx lldpd[10067]: unable to find br0 in /proc/net/bonding or /proc/self/net/bonding

The systems in question are typically CentOS 6.3 and CentOS 6.4

brctl show

bridge name bridge id STP enabled interfaces
br0 8000.00221917fec8 no bond0
vnet0
vnet1
vnet2
virbr0 8000.525400a7e645 yes virbr0-nic

lldpd -v

0.7.6

lldpd -ddd -D interfaces

2013-09-14T22:42:42 [INFO/localchassis] could not open /etc/os-release
2013-09-14T22:42:42 [INFO/localchassis] lsb_release information not available
2013-09-15T02:42:42 [INFO/main] protocol LLDP enabled
2013-09-15T02:42:42 [INFO/main] protocol CDPv1 disabled
2013-09-15T02:42:42 [INFO/main] protocol CDPv2 disabled
2013-09-15T02:42:42 [INFO/main] protocol SONMP disabled
2013-09-15T02:42:42 [INFO/main] protocol EDP disabled
2013-09-15T02:42:42 [INFO/main] protocol FDP disabled
2013-09-15T02:42:42 [INFO/event] libevent 2.0.21-stable-dev initialized with epoll method
2013-09-15T02:42:42 [ DBG/interfaces] driver for eth0 is bnx2
2013-09-15T02:42:42 [ DBG/interfaces] driver for bond0 is bonding
2013-09-15T02:42:42 [ DBG/interfaces] driver for br0 is bridge
2013-09-15T02:42:42 [ DBG/interfaces] driver for virbr0 is bridge
2013-09-15T02:42:42 [ DBG/interfaces] driver for vnet1 is tun
2013-09-15T02:42:42 [ DBG/interfaces] driver for vnet0 is tun
2013-09-15T02:42:42 [ DBG/interfaces] driver for vnet2 is tun
2013-09-15T02:42:42 [ DBG/interfaces] port bond0 is bridged to br0
2013-09-15T02:42:42 [ DBG/interfaces] port vnet1 is bridged to br0
2013-09-15T02:42:42 [ DBG/interfaces] port vnet0 is bridged to br0
2013-09-14T22:42:42 [INFO/lldpctl] cannot find configuration file/directory /etc/lldpd.conf
2013-09-14T22:42:42 [INFO/lldpctl] cannot find configuration file/directory /etc/lldpd.d
2013-09-15T02:42:42 [ DBG/interfaces] port vnet2 is bridged to br0
2013-09-14T22:42:42 [ DBG/lldpctl] connect to lldpd
2013-09-15T02:42:42 [ DBG/interfaces] interface br0 is a bridge
2013-09-14T22:42:42 [ DBG/lldpctl] argument 00: resume
2013-09-14T22:42:42 [ DBG/lldpctl] process argument 00: resume
2013-09-14T22:42:42 [ DBG/lldpctl] process argument 01: <CR>
2013-09-15T02:42:42 [ DBG/interfaces] interface virbr0 is a bridge
2013-09-15T02:42:42 [ DBG/interfaces] cannot get interface for index eth1
2013-09-15T02:42:42 [ DBG/interfaces] interface bond0 is a bond
2013-09-15T02:42:42 [ DBG/interfaces] get MAC address for bond0
2013-09-15T02:42:42 [WARN/interfaces] unable to find br0 in /proc/net/bonding or /proc/self/net/bonding
2013-09-15T02:42:42 [ DBG/interfaces] eth0 is a physical interface
2013-09-15T02:42:42 [ DBG/interfaces] vnet1 is a physical interface
2013-09-15T02:42:42 [ DBG/interfaces] vnet0 is a physical interface
2013-09-15T02:42:42 [ DBG/interfaces] vnet2 is a physical interface
2013-09-15T02:42:42 [ DBG/interfaces] eth0 is an acceptable bonded device (master=bond0)
2013-09-15T02:42:42 [ DBG/interfaces] initialize bonded device eth0
2013-09-15T02:42:42 [INFO/interfaces] unable to add LLDP address to multicast filter for
2013-09-15T02:42:42 [ DBG/interfaces] interface eth0 initialized (fd=9,master=[10])
2013-09-15T02:42:42 [ DBG/interfaces] use ifname and MAC address for eth0
2013-09-15T02:42:42 [ DBG/interfaces] vnet1 is an acceptable ethernet device
2013-09-15T02:42:42 [ DBG/interfaces] initialize ethernet device vnet1
2013-09-15T02:42:42 [ DBG/interfaces] interface vnet1 initialized (fd=11)
2013-09-15T02:42:42 [ DBG/interfaces] use ifname and MAC address for vnet1
2013-09-15T02:42:42 [ DBG/interfaces] vnet0 is an acceptable ethernet device
2013-09-15T02:42:42 [ DBG/interfaces] initialize ethernet device vnet0
2013-09-15T02:42:42 [ DBG/interfaces] interface vnet0 initialized (fd=12)
2013-09-15T02:42:42 [ DBG/interfaces] use ifname and MAC address for vnet0
2013-09-15T02:42:42 [ DBG/interfaces] vnet2 is an acceptable ethernet device
2013-09-15T02:42:42 [ DBG/interfaces] initialize ethernet device vnet2
2013-09-15T02:42:42 [ DBG/interfaces] interface vnet2 initialized (fd=13)
2013-09-15T02:42:42 [ DBG/interfaces] use ifname and MAC address for vnet2
2013-09-15T02:42:42 [ DBG/interfaces] add management address 192.168.34.35
2013-09-15T02:42:42 [ DBG/interfaces] ask ethtool for the appropriate MAC/PHY for eth0
2013-09-15T02:42:42 [ DBG/interfaces] ask ethtool for the appropriate MAC/PHY for vnet1
2013-09-15T02:42:42 [ DBG/interfaces] ask ethtool for the appropriate MAC/PHY for vnet0
2013-09-15T02:42:42 [ DBG/interfaces] ask ethtool for the appropriate MAC/PHY for vnet2
2013-09-15T02:42:42 [ DBG/interfaces] subscribe to netlink notifications
2013-09-15T02:42:42 [INFO/localchassis] change detected for port eth0, resetting its timer
2013-09-15T02:42:42 [INFO/localchassis] change detected for port vnet1, resetting its timer
2013-09-15T02:42:42 [INFO/localchassis] change detected for port vnet0, resetting its timer
2013-09-15T02:42:42 [INFO/localchassis] change detected for port vnet2, resetting its timer
2013-09-15T02:42:42 [ DBG/interfaces] driver for eth0 is bnx2
2013-09-15T02:42:42 [ DBG/interfaces] driver for bond0 is bonding
2013-09-15T02:42:42 [ DBG/interfaces] driver for br0 is bridge
2013-09-15T02:42:42 [ DBG/interfaces] driver for virbr0 is bridge
2013-09-15T02:42:42 [ DBG/interfaces] driver for vnet1 is tun
2013-09-15T02:42:42 [ DBG/interfaces] driver for vnet0 is tun
2013-09-15T02:42:42 [ DBG/interfaces] driver for vnet2 is tun
2013-09-15T02:42:42 [ DBG/interfaces] port bond0 is bridged to br0
2013-09-15T02:42:42 [ DBG/interfaces] port vnet1 is bridged to br0
2013-09-15T02:42:42 [ DBG/interfaces] port vnet0 is bridged to br0
2013-09-15T02:42:42 [ DBG/interfaces] port vnet2 is bridged to br0
2013-09-15T02:42:42 [ DBG/interfaces] interface br0 is a bridge
2013-09-15T02:42:42 [ DBG/interfaces] interface virbr0 is a bridge
2013-09-15T02:42:42 [ DBG/interfaces] cannot get interface for index eth1
2013-09-15T02:42:42 [ DBG/interfaces] interface bond0 is a bond
2013-09-15T02:42:42 [ DBG/interfaces] get MAC address for bond0
2013-09-15T02:42:42 [WARN/interfaces] unable to find br0 in /proc/net/bonding or /proc/self/net/bonding
2013-09-15T02:42:42 [ DBG/interfaces] eth0 is a physical interface
2013-09-15T02:42:42 [ DBG/interfaces] vnet1 is a physical interface
2013-09-15T02:42:42 [ DBG/interfaces] vnet0 is a physical interface
2013-09-15T02:42:42 [ DBG/interfaces] vnet2 is a physical interface
2013-09-15T02:42:42 [ DBG/interfaces] eth0 is an acceptable bonded device (master=bond0)
2013-09-15T02:42:42 [ DBG/interfaces] use ifname and MAC address for eth0
2013-09-15T02:42:42 [ DBG/interfaces] vnet1 is an acceptable ethernet device
2013-09-15T02:42:42 [ DBG/interfaces] use ifname and MAC address for vnet1
2013-09-15T02:42:42 [ DBG/interfaces] vnet0 is an acceptable ethernet device
2013-09-15T02:42:42 [ DBG/interfaces] use ifname and MAC address for vnet0
2013-09-15T02:42:42 [ DBG/interfaces] vnet2 is an acceptable ethernet device
2013-09-15T02:42:42 [ DBG/interfaces] use ifname and MAC address for vnet2
2013-09-15T02:42:42 [ DBG/interfaces] add management address 192.168.34.35
2013-09-15T02:42:42 [ DBG/interfaces] ask ethtool for the appropriate MAC/PHY for eth0
2013-09-15T02:42:42 [ DBG/interfaces] ask ethtool for the appropriate MAC/PHY for vnet1
2013-09-15T02:42:42 [ DBG/interfaces] ask ethtool for the appropriate MAC/PHY for vnet0
2013-09-15T02:42:42 [ DBG/interfaces] ask ethtool for the appropriate MAC/PHY for vnet2
2013-09-15T02:42:42 [ DBG/interfaces] send PDU to bonded device eth0
2013-09-15T02:42:42 [ DBG/interfaces] send PDU to ethernet device vnet1 (fd=11)
2013-09-15T02:42:42 [ DBG/interfaces] send PDU to ethernet device vnet0 (fd=12)
2013-09-15T02:42:42 [ DBG/interfaces] send PDU to ethernet device vnet2 (fd=13)
2013-09-15T02:42:42 [ DBG/interfaces] receive PDU from bonded device eth0
2013-09-14T22:42:42 [INFO/lldpctl] lldpd should resume operations
2013-09-15T02:42:42 [ DBG/interfaces] receive PDU from bonded device eth0
2013-09-15T02:42:42 [ DBG/interfaces] receive PDU from bonded device eth0
2013-09-15T02:42:42 [ DBG/interfaces] receive PDU from bonded device eth0
2013-09-15T02:42:47 [ DBG/interfaces] receive PDU from bonded device eth0
2013-09-15T02:42:47 [ DBG/interfaces] receive PDU from bonded device eth0
2013-09-15T02:42:47 [ DBG/interfaces] receive PDU from ethernet device vnet2
2013-09-15T02:42:47 [ DBG/interfaces] receive PDU from ethernet device vnet0
2013-09-15T02:42:47 [ DBG/interfaces] receive PDU from ethernet device vnet1
2013-09-15T02:42:47 [ DBG/interfaces] receive PDU from bonded device eth0
2013-09-15T02:42:47 [ DBG/interfaces] receive PDU from bonded device eth0
2013-09-15T02:42:47 [ DBG/interfaces] receive PDU from bonded device eth0
2013-09-15T02:42:47 [ DBG/interfaces] receive PDU from bonded device eth0
2013-09-15T02:43:12 [ DBG/interfaces] send PDU to ethernet device vnet0 (fd=12)
2013-09-15T02:43:12 [ DBG/interfaces] send PDU to bonded device eth0
2013-09-15T02:43:12 [ DBG/interfaces] send PDU to ethernet device vnet2 (fd=13)
2013-09-15T02:43:12 [ DBG/interfaces] send PDU to ethernet device vnet1 (fd=11)
2013-09-15T02:43:12 [ DBG/interfaces] receive PDU from bonded device eth0
2013-09-15T02:43:12 [ DBG/interfaces] receive PDU from bonded device eth0
2013-09-15T02:43:12 [ DBG/interfaces] receive PDU from bonded device eth0
2013-09-15T02:43:12 [ DBG/interfaces] receive PDU from bonded device eth0
2013-09-15T02:43:42 [ DBG/interfaces] send PDU to ethernet device vnet0 (fd=12)
2013-09-15T02:43:42 [ DBG/interfaces] send PDU to ethernet device vnet1 (fd=11)
2013-09-15T02:43:42 [ DBG/interfaces] send PDU to ethernet device vnet2 (fd=13)
2013-09-15T02:43:42 [ DBG/interfaces] send PDU to bonded device eth0
2013-09-15T02:43:42 [ DBG/interfaces] receive PDU from bonded device eth0
2013-09-15T02:43:42 [ DBG/interfaces] receive PDU from bonded device eth0
2013-09-15T02:43:42 [ DBG/interfaces] receive PDU from bonded device eth0
2013-09-15T02:43:42 [ DBG/interfaces] receive PDU from bonded device eth0
2013-09-15T02:43:47 [ DBG/interfaces] receive PDU from bonded device eth0
2013-09-15T02:43:47 [ DBG/interfaces] receive PDU from bonded device eth0
2013-09-15T02:43:47 [ DBG/interfaces] receive PDU from ethernet device vnet2
2013-09-15T02:43:47 [ DBG/interfaces] receive PDU from ethernet device vnet0
2013-09-15T02:43:47 [ DBG/interfaces] receive PDU from ethernet device vnet1
2013-09-15T02:43:47 [ DBG/interfaces] receive PDU from bonded device eth0
2013-09-15T02:43:47 [ DBG/interfaces] receive PDU from bonded device eth0
2013-09-15T02:43:47 [ DBG/interfaces] receive PDU from bonded device eth0

Query neighbor information from a C program?

Hi,
I am new in lldpd, and I would like to query neighbor information from my C program. Here is the code to fetch lldpd information using APIs of lldpctl.h. Could you tell me what am I doing wrong? How to fetch the information correctly-

include <lldpctl.h>

include <string.h>

include <stdio.h>

include <stdlib.h>

include <unistd.h>

ssize_t rcvfromlldpd(lldpctl_conn_t *lpctcon, const uint8_t *data, size_t length, void *udata){
int i;
printf("rcvd: ");
for(i=0;i<length;i++)
printf("%02X ",data[i]);
printf("\n");
return length;
}

ssize_t sendtolldpd(lldpctl_conn_t *lpctcon, const uint8_t *data, size_t length, void *udata){
int i;
printf("send: ");
for(i=0;i<length;i++)
printf("%02X ",data[i]);
printf("\n");
return length;
}

define userdata "lldpctl -f plain"

int main(int argc, char** argv) {
struct lldpctl_conn_t *lpct;
uint8_t data[2048]={0};
size_t length;
lpct=lldpctl_new(sendtolldpd,rcvfromlldpd, (void *)userdata);
while(1)
{
// lldpctl_send(lpct);
lldpctl_recv(lpct,data,length);
lldpctl_release(lpct);
}
return 0;
}

Thank you.

Implement a proper event loop

Current lldpd event loop is basic. A classic event loop will help to implement other issues. Instead of reimplementing a new event loop, libevent could be used.

Inconsistent key naming in keyvalue output

for
lldpctl -f keyvalue

root@darkstar:~# lldpd -v
lldpd version: 0.5.7

lldp.eth2.port.ifname=TenGigabitEthernet0/2
lldp.eth2.port.descr=TenGigabitEthernet0/2
lldp.eth2.vlan.vlan-id=1
lldp.eth2.vlan.pvid=yes
lldp.eth2.vlan=VLAN #1
lldp.eth4.via=LLDP
lldp.eth4.rid=4

lldp.eth2.vlan should perhaps be lldp.eth2.vlan.name (chassis and port are like this)

as otherwise you have a key with a value, but also a subtree. there are no other values i can see with sub tree.

I hope i am making sense.

I am trying to parse these in to a perl hash, and its hurting because of this :(

MED location configuration fails from lldpcli

Hi Vincent,

i just intstalled version 0.7.2 and i'm unable to setup coordinate and civic locations. ELIN works fine for me. I also installed 0.7.0 and 0.7.1 but both didn't recognized the "med" command at all.

Tried it on ubuntu 12.10 and 13.04.

Here is the output. The Command is from your documentation tried it with and without ports:

[lldpcli] # configure ports eth0 med location coordinate latitude 48.85667N longitude 2.2014E altitude 117.47m datum WGS84
2013-04-30T11:56:54 [WARN/lldpctl] unknown command from argument 13: `datum`

[lldpcli] # configure med location coordinate latitude 48.85667N longitude 2.2014E altitude 117.47m datum WGS84
2013-04-30T11:57:03 [WARN/lldpctl] unknown command from argument 11: `datum`

Regards
Phil

Windows support?

It'd be nice to have a cross-platform tool that plays nice on Windows, as well.

Of course, since your options are terrible NDIS calls or WinPcap, that would be a bit of complexity, but given the interface-$OS.c already extant, what's one more domain-specific file? ;)

(I'll probably give a go to at least getting most of it compiling under Windows before I try to crap out some Win-specific code, I just wanted to file an issue about it as well to track anyone else's progress, including mine!)

Add IPv6 support for management address

Currrently, lldpd is only able to store one IPv4 address as a management address. Adding support to store several IPv4 addresses and several IPv6 addresses would be better.

Limit the number of neighbors on a given port

Each port should only accept a limited number of neighbors. When this maximum is reached, no new neighbors should be accepted. If the older ones were bogus, they will eventually expire.

Maybe the maximum number of neighbors should be per protocol? We should at least arrange to accept as many neighbors as there are protocols.

lldpd syslog messages not logging in local time

We are seeing an issue with lldpd when it writes to syslog, the timestamp is in GMT and not local. All other messages are coming across as local time.

Feb 14 19:50:42 XXXXXXXXXXX last message repeated 13 times
Feb 14 19:51:17 XXXXXXXXXXX last message repeated 7 times
Feb 14 13:51:20 XXXXXXXXXXX sshd[10194]: Accepted publickey for root from XXXXXXXXX port 47966 ssh2
Feb 14 19:51:22 XXXXXXXXXXX lldpd[17713]: lldpd_decode: unable to guess frame type
Feb 14 19:51:47 XXXXXXXXXXX last message repeated 5 times
Feb 14 13:51:49 XXXXXXXXXXX sshd[10231]: Accepted publickey for timecheck from XXXXXXXXXXX port 48430 ssh2
Feb 14 19:51:52 XXXXXXXXXXX lldpd[17713]: lldpd_decode: unable to guess frame type
Feb 14 19:52:27 XXXXXXXXXXX last message repeated 7 times
Feb 14 19:53:32 XXXXXXXXXXX last message repeated 13 times
Feb 14 19:54:12 XXXXXXXXXXX last message repeated 8 times
Feb 14 13:54:12 XXXXXXXXXXX sshd[10252]: Accepted publickey for root from XXXXXXXXXXX port 33299 ssh2
Feb 14 13:54:17 XXXXXXXXXXX sshd[10286]: Accepted publickey for monitor from XXXXXXXXXXX port 56177 ssh2
Feb 14 19:54:17 XXXXXXXXXXX lldpd[17713]: lldpd_decode: unable to guess frame type

All-Zeros MAC address on bonded interfaces

Using latest lldpd (lldpd-0.7.1-4.1.x86_64) RPM on a CentOS6.3 system, we find that the source MAC address of both CDP and LLDP packets issued by lldpd is All-Zeros, rather than the hardware address of the specific interface within the bond, as might be expected.

Using the same version of lldpd ( albeit i686 version ) on a different CentOS6.3 system with a non-bonded eth0, the normal hardware MAC address is used.

Fortunately, the issue doesn't appear to cause a huge problem, as upstream Cisco Switches we're using seem to ignore the source MAC, and don't seem to atttempt to add the all-zeros address to their bridging tables ( because the CDP/LLDP packets are not intended to be bridged, of course ).

Selection of 'Chassis ID'

In the situation where multiple nics are installed, the 'Chassis ID' seems to be the nic with the lowest mac address.

This is annoying for myself (though far from fatal) as our 'eth0' is a larger mac address than 'eth1' - so eth1 becomes 'chassis id'

I cant see how this could be configured, i could be wrong

Is this something that can be controlled?

Support of GRE tunnel

LLDP could be used into a GRE tunnel. It needs to be encapsulated into a LLC/SNAP frame. From 802.1ab:

Where the LLC entity uses an MSAP that is supported by a specific media access control method (for
example, IEEE Std 802.3-2002, IEEE Std 802.11-1999) or a media access control independent entity (for
example, IEEE P802.1AE) that directly supports encoding of Ethertypes, the LLC entity shall encode the
LLDP Ethertype as the two octet LLDPDU header in the MSDU of the corresponding MAC service request.

Where the LLC entity uses an MSAP that is supported by a specific media access control method (for
example, IEEE Std 802.5) that does not directly support Ethertype encoding, the LLDP Ethertype shall be
encoded in the octets of LLDPDU header according to the procedures specified in IEEE Std 802-2001 for
Subnetwork Access Protocols (SNAP).

NOTES
1—The SNAP discriminator comprises the octets AA-AA-03-00-00-00 prepended to the LLDP Ethertype.
2—Annex D provides example LLDP transmission frame formats for both direct-encoded and SNAP-encoded LLDP
Ethertype encoding methods.

Installation on OS X 10.8 fails on make

make
make all-recursive
Making all in src/compat
CC empty.lo
CCLD libcompat.la
/usr/bin/ranlib: file: .libs/libcompat.a(empty.o) has no symbols
ranlib: file: .libs/libcompat.a(empty.o) has no symbols
ranlib: warning for library: .libs/libcompat.a the table of contents is empty (no object file members in the library define global symbols)
Making all in src
CC log.lo
CC marshal.lo
CC ctl.lo
CC lldpd-structs.lo
CCLD libcommon-daemon-lib.la
/usr/bin/ranlib: file: .libs/libcommon-daemon-lib.a(empty.o) has no symbols
ranlib: file: .libs/libcommon-daemon-lib.a(empty.o) has no symbols
CCLD libcommon-daemon-client.la
/usr/bin/ranlib: file: .libs/libcommon-daemon-client.a(empty.o) has no symbols
ranlib: file: .libs/libcommon-daemon-client.a(empty.o) has no symbols
Making all in src/daemon
CC liblldpd_la-frame.lo
CC liblldpd_la-lldp.lo
CC liblldpd_la-cdp.lo
CC liblldpd_la-sonmp.lo
CC liblldpd_la-edp.lo
CC liblldpd_la-client.lo
CC liblldpd_la-priv.lo
CC liblldpd_la-privsep_fdpass.lo
CC liblldpd_la-interfaces.lo
CC liblldpd_la-event.lo
CC liblldpd_la-lldpd.lo
CC liblldpd_la-interfaces-bsd.lo
CC liblldpd_la-dmi-osx.lo
In file included from /System/Library/Frameworks/CoreFoundation.framework/Headers/CFBase.h:146,
from /System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:38,
from dmi-osx.c:20:
/usr/include/MacTypes.h: In function 'Debugger':
/usr/include/MacTypes.h:693: error: expected declaration specifiers before '__AVAILABILITY_INTERNAL__MAC_10_0_DEP__MAC_10_8'
compilation terminated due to -Wfatal-errors.
{standard input}:2:FATAL:.abort detected. Assembly stopping.
make[2]: *** [liblldpd_la-dmi-osx.lo] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

'unable to guess frame type of ethX'

Hi there, im running 0.6.0 on rhel6, and seeing lots of these in the syslog file...

May 30 14:28:32 lteftp01 lldpd[3248]: lldpd_decode: unable to guess frame type on eth0
May 30 14:28:35 lteftp01 lldpd[3248]: lldpd_decode: unable to guess frame type on eth1

This machine is connected to a nexus switch

[root@lteftp01 users]# lldpctl

LLDP neighbors:

Interface: eth1, via: LLDP, RID: 1, Time: 0 day, 00:05:55
Chassis:
ChassisID: mac 54:7f:ee:59:3d:31
SysName: XXXXXXX
SysDescr: Cisco Nexus Operating System (NX-OS) Software
TAC support: http://www.cisco.com/tac
Copyright (c) 2002-2011, Cisco Systems, Inc. All rights reserved.
MgmtIP: XXXXXX
Capability: Bridge, on
Port:
PortID: local Eth1/10
PortDescr: Ethernet1/10

VLAN: 24, pvid: yes

Interface: eth0, via: LLDP, RID: 2, Time: 0 day, 00:05:55
Chassis:
ChassisID: mac 54:7f:ee:58:d1:b1
SysName: XXXX
SysDescr: Cisco Nexus Operating System (NX-OS) Software
TAC support: http://www.cisco.com/tac
Copyright (c) 2002-2011, Cisco Systems, Inc. All rights reserved.
MgmtIP: XXXX
Capability: Bridge, on
Port:
PortID: local Eth1/10
PortDescr: Ethernet1/10

VLAN: 24, pvid: yes

lldpd triggers bridge module load

On a Citrix Xenserver system where linux bridge has been replaced in favor of Open vSwitch, lldpd seems to attempt to load the bridge kernel module.

When executed with flags to only care about receiving of lldp frames, specifically with runtime flags of "-i -k -r -I" the follow messages get dumped:

localhost kernel: bridge: exports duplicate symbol br_should_route_hook (owned by openvswitch_mod)
localhost modprobe: FATAL: Error inserting bridge (/lib/modules/2.6.32.12-0.7.1.xs5.6.100.323.170596xen/kernel/net/bridge/bridge.ko): Invalid module format

Is there something that can be configured to prevent this action from taking place? Thanks!

lldpcli is unable to retrieve neighbors when there is too many of them

Here is a proposed fix by Chris Yang:

/* Statiscally receive data from remote end. */
static ssize_t
sync_recv(lldpctl_conn_t *lldpctl,
    const uint8_t *data, size_t length, void *user_data)
{
    struct lldpctl_conn_sync_t *conn = user_data;
    size_t nb;
#if defined(LLDP_FIX)
    size_t remain, offset = 0;
#endif
    if (conn->fd == -1 &&
        ((conn->fd = sync_connect()) == -1)) {
        lldpctl->error = LLDPCTL_ERR_CANNOT_CONNECT;
        return LLDPCTL_ERR_CANNOT_CONNECT;
    }
#if defined(LLDP_FIX)
    remain = length;
    do {
        if ((nb = read(conn->fd, (void*)data + offset, remain)) == -1)
            if (errno == EAGAIN || errno == EINTR) continue;
        remain -= nb;
        offset += nb;
    } while (remain > 0);
    return offset;
#else
    while ((nb = read(conn->fd, (void*)data, length)) == -1) {
        if (errno == EAGAIN || errno == EINTR) continue;
        return LLDPCTL_ERR_CALLBACK_FAILURE;
    }
    return nb;
#endif
}

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.