lldpd/lldpd

implementation of IEEE 802.1ab (LLDP)

lldpd's Issues

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.

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.

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

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

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

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?

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 ).

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

lldpd doesn't set the station capabilities

Hello
lldpd doesn't set the station capabilities in system and enabled capabilities.

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


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,

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

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

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

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.

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!)

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.

Need to push the tag for 0.7.3.

It looks like the tag for 0.7.3 was never pushed, but the tarball is available on the website. :-)

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

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!

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 ?

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.

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

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.

--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.

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
  

display_port

[email protected] display_port requires a port atom
however, [email protected], the usage is passed a neighbor atom.

Disregard how misleading might it be, Is this intended?

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.

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

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?

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.

request support for LLTP support

http://www.veerkade.com/lld2d/
LLTP, from Microsoft

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

Visibility of link aggregation information

Hello, I am curious if lldpctl or lldpcli show the link aggregation information that is provided by neighbours?

Configure manangement ip pattern from lldpcli

Hello. I would like to set the management ip (-m) in the lldpd.conf file but there does not seem to be support for this at the moment.

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);

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)

FreeBSD support

Add FreeBSD support to lldpd.

'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

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.

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.

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
}

Minor license change

Hi,

I noticed that lldpd seems to have a slightly older version of the ISC License. To avoid ambiguity they "recently" changed an "and" to an "and/or" in the first sentence. See http://en.wikipedia.org/wiki/ISC_license for details.

Thank you for a great piece of software!

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 :(

Add an option to listen only on some interfaces

See:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=584806

lldpd seems to bind to all interfaces per default and doesn't seems
to provide a way to pick the interfaces to bind to.

This might be an unwanted feature with multi-homed servers.

Providing a parameter to give a list of interface to bind to would be
appreciated.

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))

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.

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

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.

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.