[Questions] Regarding ghost ports feature

[commodo]

Hello,

I am curious about the status on the ghost ports ?
Looks like it's not in version 0.7.17, and in trunk there is only a mention of it for version 0.8.0 in the NEWS.
But I can't make out from the sources if it's in (even partially).

I'd be fine with using trunk, since our current hack (for keeping info on custom TLVs) is showing some minor failures under some stress-tests.

Seems that trunk does not build too well ; or maybe better said, I may need some hints on building trunk.
I get either:

Checking for LIBEVENT... yes
checking if system libevent works as expected... yes
=== configuring in libevent (/home/sandu/work/Wrt/openwrt/build_dir/target-powerpc_8540_uClibc-0.9.33.2_ewok/lldpd-0.8.0-trunk/libevent)
configure: running /bin/sh ./configure --disable-option-checking '--prefix=/usr'  '--target=powerpc-openwrt-linux' '--host=powerpc-openwrt-linux' '--build=x86_64-suse-linux' '--program-prefix=' '--program-suffix=' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--libexecdir=/usr/lib' '--sysconfdir=/etc' '--datadir=/usr/share' '--localstatedir=/var' '--mandir=/usr/man' '--infodir=/usr/info' '--disable-nls' '--with-privsep-user=lldp' '--with-privsep-group=lldp' '--with-privsep-chroot=/var/run/lldp' '--with-readline=no' '--with-embedded-libevent=no' '--with-embedded-libnl=no' '--disable-hardening' '--without-xml' '--disable-cdp' '--disable-fdp' '--disable-edp' '--disable-lldpmed' '--disable-dot1' '--disable-dot3' '--disable-sonmp' '--with-json=json-c' 'build_alias=x86_64-suse-linux' 'host_alias=powerpc-openwrt-linux' 'target_alias=powerpc-openwrt-linux' 'CC=powerpc-openwrt-linux-uclibcspe-gcc' 'CFLAGS=-Os -pipe -mcpu=8540 -g3 -fno-caller-saves -fhonour-copts -Wno-error=unused-but-set-variable --std=c99 ' 'LDFLAGS=-L/home/sandu/work/Wrt/openwrt/staging_dir/target-powerpc_8540_uClibc-0.9.33.2_ewok/usr/lib -L/home/sandu/work/Wrt/openwrt/staging_dir/target-powerpc_8540_uClibc-0.9.33.2_ewok/lib -L/home/sandu/work/Wrt/openwrt/staging_dir/toolchain-powerpc_8540_gcc-4.8-linaro_uClibc-0.9.33.2/usr/lib -L/home/sandu/work/Wrt/openwrt/staging_dir/toolchain-powerpc_8540_gcc-4.8-linaro_uClibc-0.9.33.2/lib ' 'CPPFLAGS=-I/home/sandu/work/Wrt/openwrt/staging_dir/target-powerpc_8540_uClibc-0.9.33.2_ewok/usr/include -I/home/sandu/work/Wrt/openwrt/staging_dir/target-powerpc_8540_uClibc-0.9.33.2_ewok/include -I/home/sandu/work/Wrt/openwrt/staging_dir/toolchain-powerpc_8540_gcc-4.8-linaro_uClibc-0.9.33.2/usr/include -I/home/sandu/work/Wrt/openwrt/staging_dir/toolchain-powerpc_8540_gcc-4.8-linaro_uClibc-0.9.33.2/include ' 'CXX=powerpc-openwrt-linux-uclibcspe-g++' 'CXXFLAGS=-Os -pipe -mcpu=8540 -g3 -fno-caller-saves -fhonour-copts -Wno-error=unused-but-set-variable --std=c99 ' 'PKG_CONFIG=/home/sandu/work/Wrt/openwrt/staging_dir/host/bin/pkg-config' 'PKG_CONFIG_PATH=/home/sandu/work/Wrt/openwrt/staging_dir/target-powerpc_8540_uClibc-0.9.33.2_ewok/usr/lib/pkgconfig:/home/sandu/work/Wrt/openwrt/staging_dir/target-powerpc_8540_uClibc-0.9.33.2_ewok/usr/share/pkgconfig' 'PKG_CONFIG_LIBDIR=/home/sandu/work/Wrt/openwrt/staging_dir/target-powerpc_8540_uClibc-0.9.33.2_ewok/usr/lib/pkgconfig:/home/sandu/work/Wrt/openwrt/staging_dir/target-powerpc_8540_uClibc-0.9.33.2_ewok/usr/share/pkgconfig' --enable-silent-rules  --disable-libevent-regress --disable-thread-support --disable-openssl --disable-malloc-replacement --disable-debug-mode --enable-function-sections --disable-shared --with-pic --enable-static --cache-file=/dev/null --srcdir=.
/bin/sh: ./configure: No such file or directory

either

config.status: error: cannot find input file: `Makefile.in

Anyway, moving forward, if possible, I'd like to help out with this feature, since it's one of current burning issues, and we've managed to get up to now without it (and hacking stuff up), but our current direction is to get this properly in.

As a note, on OpenWRT, there are 2 libnl libs (libnl + libnl-tiny (a stripdown of libl)) , so if something should have worked [or should work] for me [ and did not ], it could be because I tried with libnl-tiny right now.
I am not yet sure of the feature conpleteness of libnl-tiny.

Thanks :)
Alex

[vincentbernat]

You are the second one to get this error at build. Did you use ./autogen.sh?

What is implemented in trunk is that there is a default port that is cloned when new ports are created. Therefore, when configuring something on all ports, it gets configured on the default port as well and new ports will inherit it. Moreover, ports are not removed when they get down, so the configuration stays.

What is not done is configuring a port that doesn't exist yet.

The error you got is not related to libnl. I am not relying on AC_CONFIG_SUBDIRS anymore because this macro doesn't allow to use custom configure options in a subdir. You have to mutate the current options to add the options you want and all the configure will use the same option. That did work with libevent but I cannot do that with both libevent and libnl (some options for libevent doesn't work in libnl). So, I use a custom version. So I have custom bugs.

[vincentbernat]

And as for libnl-tiny, if there is enough in it, I'd be willing to make it work with it too (it should be OK as long as libnl-route is here).

[commodo]

libnl-tiny is a bit OpenWRT specific ;
I guess it could be adapted to work outside of OpenWRT context
Here's some sources from my fork https://github.com/commodo/openwrt/tree/master/package/libs/libnl-tiny/src

I'll try to run autogen.sh ; though I might just do a diff + patch between 0.7.17 and 0.8.0 and apply that in our tree and run it like that.

[vincentbernat]

The build system in 0.7.17 is the same as in 0.8.0 (I did the same update). It would help me if it worked. ;-)

[vincentbernat]

For libnl-tiny, it seems that there is no code for libnl-route, so it won't work (libnl-route also gives link and addresses, despite its name).

[vincentbernat]

For the build issue, have a look at #133 and the fix proposed. I hope you did hit the same case.

[commodo]

Thanks for the notification.
Will check.

[commodo]

This also fixed it for me :)
Thanks.

As for the libnl-tiny part ; I've tried to port bits to it from libnl.
After seeing it blow in size ( 2x ) I decided that OpenWRT upstream would not like that much, so it would be a useless effort to do that.
So, we've switched to libnl.

This seems to work fairly well ; there are 2 cases I am seeing:

• on 1 interface (which is an uplink), when I pull the plug, lldpctl will still show the LLDP info from the partner
• [on other interfaces, switch port interfaces] if I pull the plug the info lldpctl will disappear reasonably quick, but we I put the cable back it will take about 10-20 seconds to get back, which is a bit much

Regarding the first point, I will check and see the code, and try to understand why the netlink event does not affect uplink ports.
Regarding the second, I'll see about tweaking the time there to get it down to 5 seconds.
On OpenWRT we can also write some hotplug scripts that would call lldpcli update as a workaround for now

Thanks :)

[vincentbernat]

For the second point, I think this is expected: we have to receive LLDP frames to be able to assert any information. We cannot reuse the old information (which has been discarded) because we may have been plugged to a different port.

[commodo]

Ah, on 1st point we seem to have found an issue with link-state events not occurring.
So, false alarm here for lldpd

[vincentbernat]

Good news. Always better when the problems are not on my side. ;-)

[commodo]

For the second point.
Is there a way to speed this up a bit ?
Or this would just mean that some performance tweaks are needed ?

I think for now we could live with 10-20 seconds, especially since that info is guaranteed to be solid.
I don't have too much time to investigate deeper into this right now, so, I may come back on this later, hopefully then with some findings (possibly even tweaks).

Regarding libnl-tiny vs libnl
We eventually went ahead with using libnl + libnl-route.
We've had to split that package (in OpenWRT) into smaller packages, so that we can have a better granularity and control of size.

Thanks :)

[vincentbernat]

For the second point, we have to wait for the remote device to send LLDP frames. It seems that the device on your upstream link is sending LLDP frames when link comes up but this is not the case on the other ports. I don't see what can be done about this. lldpd publish the information about new peer as soon as it receives them. Check with tcpdump that no incoming frames are available when you plug the cord.

[commodo]

hmmm, ok :)
thanks for the help

will keep looking here later; it may be that some of our kernel stuff may need tweaking
I think this can be closed for now; I've got all I need

thanks again