sspans / ladvd Goto Github PK
View Code? Open in Web Editor NEWLLDP / CDP Daemon for Unix
LLDP / CDP Daemon for Unix
Subject!
Running from the latest on github as of today, we're seeing the following scenario:
ladvdc hangs before printing the first device (ctrl-c is necessary):
$ ladvdc
Capability Codes:
r - Repeater, B - Bridge, H - Host, R - Router, S - Switch,
W - WLAN Access Point, C - DOCSIS Device, T - Telephone, O - Other
Device ID Local Intf Proto Hold-time Capability Port ID
^C
The ladvd child seems to be in skb_recv_datagram and the parent in sock_alloc_send_pskb, before, during, and running ladvdc.
%CPU %MEM PSR LIM WCHAN NI PAGEIN LWP PID PPID PRI RSS STARTED S TIME SZ TT UID USER VSZ COMMAND
0.0 0.0 0 xx sock_alloc_send_pskb 0 0 5242 5242 1 19 18240 Mar 04 S 00:00:00 12344 ? 0 root 49376 ladvd: parent [priv]
0.0 0.0 2 xx skb_recv_datagram 0 0 5244 5244 5242 19 704 Mar 04 S 00:00:00 8041 ? 100 ladvd 32164 ladvd: child
0.0 0.0 4 xx skb_recv_datagram 0 0 8720 8720 8443 19 640 10:51:02 S 00:00:00 5420 pts/0 0 root 21680 ladvdc
Restarting ladvd (sigkill is necessary) fixes the problem, at least temporarily, so it feels like a race or deadlock of some sort, perhaps?
Note that this is running on Debian Wheezy with kernel 3.14.32, libc 2.17.
Hi,
I am using ladvd, compiled from source on a Raspberry Pi.
Linux raspberrypi 4.1.13-v7+ #826 SMP PREEMPT Fri Nov 13 20:19:03 GMT 2015 armv7l GNU/Linux
The daemon is working as intended, its sending LLDP PDUs as expected. On other x86 based machines, I can view the LLDP table with the populated devices, including the Raspberry Pi.
Then I have another Raspberry Pi, also running ladvd. I try to view the LLDP neighbors by running ladvdc, but the output is "stuck" at this point:
$ ladvdc
Capability Codes:
r - Repeater, B - Bridge, H - Host, R - Router, S - Switch,
W - WLAN Access Point, C - DOCSIS Device, T - Telephone, O - Other
Device ID Local Intf Proto Hold-time Capability Port ID
I then have to close ladvdc with Ctrl+C. However LLDP PDUs arrive at that device, as I confirmed with tcpdump. I can share the dumps if you like.
We're noticing that ladvd is segfault when using intel v710 25gbe cards. We're using Ubuntu 16.04 and their packaged version (1.1.1~pre1-2). Ideas?
#0 0x0000000000000000 in ?? ()
No symbol table info available.
#1 0x00007f36def2f7a6 in pci_id_cache_load (a=a@entry=0x5589cf757d90, flags=flags@entry=2097155) at names-cache.c:58
name = 0x5589cf7583a0 "//.pciids-cache"
line = "\005\000\000\000\000\000\000\000D\314}\337\066\177\000\000\000\000\000\000\000\000\000\000\270\b\000\000\000\000\000\000\330I\237\337\066\177\000\000D\314}\337\066\177\000\000\370\217U\336\066\177\000\000\220\006\000\000\000\000\000\000\330I\237\337\066\177\000\000D\314}\337\066\177\000\000\370\217U\336\066\177\000\000f\005\000\000\000\000\000\000\330I\237\337\066\177\000\000\200\275T\336\066\177\000\000\370\217U\336\066\177\000\000{\324}\337\066\177\000\000f\005\000\000\000\000\000\000\370\217U\336\066\177\000\000\330I\237\337\066\177\000\000\330J\265\344\377\177\000\000\324J\265\344\377\177\000\000\021\316}\337\066\177\000\000\370\217U\336\066\177\000\000\340\240\362\336\066\177\000\000\300\223\362\336\066\177\000\000"...
f = <optimized out>
lino = <optimized out>
#2 0x00007f36def2d55c in id_lookup (a=a@entry=0x5589cf757d90, flags=flags@entry=2097155, cat=cat@entry=2, id1=id1@entry=32902, id2=id2@entry=5515, id3=id3@entry=0, id4=0) at names.c:25
name = <optimized out>
tried_hwdb = 0
#3 0x00007f36def2d8e8 in pci_lookup_name (a=0x5589cf757d90, buf=buf@entry=0x7fffe4b551f0 "", size=size@entry=512, flags=2097155, flags@entry=3) at names.c:162
args = <error reading variable args (Attempt to dereference a generic pointer.)>
v = <optimized out>
d = <optimized out>
cls = <optimized out>
pif = <optimized out>
iv = 32902
id = 5515
isv = <optimized out>
isd = <optimized out>
icls = <optimized out>
ipif = <optimized out>
numbuf = "8086:158b\000\000\000\000\000\000"
pifbuf = "0suωU\000\000\214\271\\\336\066\177\000\000\001\000\000\000\001\000\000\000\000\000\000\000\000\000\000"
#4 0x00005589cdb552c2 in parent_device_id (mreq=mreq@entry=0x7fffe4b551d0) at ../../src/parent.c:612
device_id = <optimized out>
vendor_id = 32902
pacc = 0x5589cf757d90
path = "/sys/class/net/enp2s0f0/device/device\000em\000\000\000\000\000\000\000\000\060suωU\000\000cS[\336\066\177\000\000\000\000\000\000\000\000\000\000\220}uωU\000\000@\000\000\000\000\000\000\000 v\265͉U\000\000\320Q\265\344\377\177\000\000\240P\265\344\377\177\000\000\001\000\000\000\000\000\000\000AN\265͉U\000\000\023\000\000\000\000\000\000\000\325\315\000\000\000\000\000\000\001\000\000\000\000\000\000\000\244\201", '\000' <repeats 23 times>, "\020\000\000\000\000\000\000\000\020", '\000' <repeats 14 times>, "\221\231/Y"...
id_str = "0x158b\000\000\214\271\\\336\066\177\000"
sub_path = "../../../../bus/pci", '\000' <repeats 236 times>
sub_base = <optimized out>
vendor_str = "\000\000\000\000\000\000\000\000@\000\000\000\000\000\000\000\060suωU\000\000\000\000\000\000\000\000\000"
device_str = "0x158b\000\000\214\271\\\336\066\177\000\000\001\000\000\000\001\000\000\000\000\000\000\000\000\000\000"
s = 0x0
ret = <optimized out>
#5 0x00005589cdb55c08 in parent_req (reqfd=4, event=<optimized out>) at ../../src/parent.c:244
mreq = {op = 5 '\005', index = 4, name = "enp2s0f0\000\000\000\000\000\000\000", len = 0, buf = '\000' <repeats 511 times>}
len = <optimized out>
__func__ = "parent_req"
#6 0x00007f36df3854c9 in event_process_active_single_queue (activeq=0x5589cf757750, base=0x5589cf757330) at event.c:1350
ev = 0x7fffe4b55530
count = 1
#7 event_process_active (base=<optimized out>) at event.c:1420
activeq = 0x5589cf757750
i = 0
c = 0
#8 event_base_loop (base=0x5589cf757330, flags=flags@entry=0) at event.c:1621
evsel = 0x7f36df5bc920 <epollops>
tv = {tv_sec = 0, tv_usec = 0}
tv_p = <optimized out>
res = <optimized out>
done = 0
retval = 0
__func__ = "event_base_loop"
#9 0x00007f36df386611 in event_loop (flags=flags@entry=0) at event.c:1533
No locals.
#10 0x00007f36df386627 in event_dispatch () at event.c:1444
No locals.
#11 0x00005589cdb5487d in parent_init (reqfd=<optimized out>, msgfd=<optimized out>, child=1292) at ../../src/parent.c:152
ev_cmd = {ev_active_next = {tqe_next = 0x0, tqe_prev = 0x5589cf757750}, ev_next = {tqe_next = 0x7fffe4b555c0, tqe_prev = 0x5589cf757490}, ev_timeout_pos = {ev_next_with_common_timeout = {
tqe_next = 0xffffffff, tqe_prev = 0x0}, min_heap_idx = -1}, ev_fd = 4, ev_base = 0x5589cf757330, _ev = {ev_io = {ev_io_next = {tqe_next = 0x0, tqe_prev = 0x5589cf757880}, ev_timeout = {tv_sec = 0,
tv_usec = 0}}, ev_signal = {ev_signal_next = {tqe_next = 0x0, tqe_prev = 0x5589cf757880}, ev_ncalls = 0, ev_pncalls = 0x0}}, ev_events = 18, ev_res = 2, ev_flags = 130, ev_pri = 0 '\000',
ev_closure = 2 '\002', ev_timeout = {tv_sec = 0, tv_usec = -1}, ev_callback = 0x5589cdb55a20 <parent_req>, ev_arg = 0x0}
ev_msg = {ev_active_next = {tqe_next = 0xffffffffffffffff, tqe_prev = 0xffffffffffffffff}, ev_next = {tqe_next = 0x5589cf757358, tqe_prev = 0x7fffe4b55540}, ev_timeout_pos = {
ev_next_with_common_timeout = {tqe_next = 0x5a5a5a5affffffff, tqe_prev = 0x5a5a5a5a5a5a5a5a}, min_heap_idx = -1}, ev_fd = 6, ev_base = 0x5589cf757330, _ev = {ev_io = {ev_io_next = {tqe_next = 0x0,
tqe_prev = 0x5589cf7578a0}, ev_timeout = {tv_sec = 0, tv_usec = 0}}, ev_signal = {ev_signal_next = {tqe_next = 0x0, tqe_prev = 0x5589cf7578a0}, ev_ncalls = 0, ev_pncalls = 0x0}}, ev_events = 18,
ev_res = 0, ev_flags = 130, ev_pri = 0 '\000', ev_closure = 2 '\002', ev_timeout = {tv_sec = 0, tv_usec = 0}, ev_callback = 0x5589cdb55c90 <parent_send>, ev_arg = 0x0}
ev_sigchld = {ev_active_next = {tqe_next = 0x5589cf754e30, tqe_prev = 0x7f36df9cb6a8}, ev_next = {tqe_next = 0x7fffe4b556e0, tqe_prev = 0x5589cf757368}, ev_timeout_pos = {ev_next_with_common_timeout = {
tqe_next = 0x5589ffffffff, tqe_prev = 0x7f36de5c2c8b <__GI__IO_default_finish+123>}, min_heap_idx = -1}, ev_fd = 17, ev_base = 0x5589cf757330, _ev = {ev_io = {ev_io_next = {tqe_next = 0x0,
tqe_prev = 0x5589cf7579d0}, ev_timeout = {tv_sec = 0, tv_usec = 0}}, ev_signal = {ev_signal_next = {tqe_next = 0x0, tqe_prev = 0x5589cf7579d0}, ev_ncalls = 0, ev_pncalls = 0x0}}, ev_events = 24,
ev_res = 0, ev_flags = 130, ev_pri = 0 '\000', ev_closure = 1 '\001', ev_timeout = {tv_sec = 1, tv_usec = 140737030477600}, ev_callback = 0x5589cdb55880 <parent_signal>, ev_arg = 0x7fffe4b5552c}
ev_sigint = {ev_active_next = {tqe_next = 0x5589cf755360, tqe_prev = 0x5589cf754400}, ev_next = {tqe_next = 0x7fffe4b55770, tqe_prev = 0x7fffe4b55660}, ev_timeout_pos = {ev_next_with_common_timeout = {
tqe_next = 0xffffffff, tqe_prev = 0x1de670bcd}, min_heap_idx = -1}, ev_fd = 2, ev_base = 0x5589cf757330, _ev = {ev_io = {ev_io_next = {tqe_next = 0x0, tqe_prev = 0x5589cf757b50}, ev_timeout = {
tv_sec = 0, tv_usec = 0}}, ev_signal = {ev_signal_next = {tqe_next = 0x0, tqe_prev = 0x5589cf757b50}, ev_ncalls = 0, ev_pncalls = 0x0}}, ev_events = 24, ev_res = 0, ev_flags = 130,
ev_pri = 0 '\000', ev_closure = 1 '\001', ev_timeout = {tv_sec = 0, tv_usec = 0}, ev_callback = 0x5589cdb55880 <parent_signal>, ev_arg = 0x7fffe4b5552c}
ev_sigterm = {ev_active_next = {tqe_next = 0x0, tqe_prev = 0x0}, ev_next = {tqe_next = 0x7fffe4b55800, tqe_prev = 0x7fffe4b556f0}, ev_timeout_pos = {ev_next_with_common_timeout = {tqe_next = 0xffffffff,
tqe_prev = 0x0}, min_heap_idx = -1}, ev_fd = 15, ev_base = 0x5589cf757330, _ev = {ev_io = {ev_io_next = {tqe_next = 0x0, tqe_prev = 0x5589cf757c10}, ev_timeout = {tv_sec = 0, tv_usec = 0}},
ev_signal = {ev_signal_next = {tqe_next = 0x0, tqe_prev = 0x5589cf757c10}, ev_ncalls = 0, ev_pncalls = 0x0}}, ev_events = 24, ev_res = 0, ev_flags = 130, ev_pri = 0 '\000', ev_closure = 1 '\001',
ev_timeout = {tv_sec = 139873638997376, tv_usec = 94050379451952}, ev_callback = 0x5589cdb55880 <parent_signal>, ev_arg = 0x7fffe4b5552c}
ev_sighup = {ev_active_next = {tqe_next = 0x5589cf754400, tqe_prev = 0x7f36de612a03 <__GI__nss_files_parse_pwent+35>}, ev_next = {tqe_next = 0x0, tqe_prev = 0x7fffe4b55780}, ev_timeout_pos = {
ev_next_with_common_timeout = {tqe_next = 0xffffffffffffffff, tqe_prev = 0x7fffe4b55888}, min_heap_idx = -1}, ev_fd = 1, ev_base = 0x5589cf757330, _ev = {ev_io = {ev_io_next = {tqe_next = 0x0,
tqe_prev = 0x5589cf757cd0}, ev_timeout = {tv_sec = 94050379431936, tv_usec = 0}}, ev_signal = {ev_signal_next = {tqe_next = 0x0, tqe_prev = 0x5589cf757cd0}, ev_ncalls = 0, ev_pncalls = 0x0}},
ev_events = 24, ev_res = 0, ev_flags = 130, ev_pri = 0 '\000', ev_closure = 1 '\001', ev_timeout = {tv_sec = 0, tv_usec = -1}, ev_callback = 0x5589cdb55880 <parent_signal>, ev_arg = 0x0}
__func__ = "parent_init"
#12 0x00005589cdb52b44 in main (argc=<optimized out>, argv=<optimized out>) at ../../src/main.c:262
ch = <optimized out>
i = <optimized out>
username = <optimized out>
pidstr = "\200Z\265\344\377\177\000\000HZ\265\344\377\177\000"
fd = <optimized out>
pwd = 0x7f36de90dd80 <resbuf>
sargc = 0
sargv = 0x5589cf754d60
cpair = {3, 4}
mpair = {5, 6}
lock = {l_type = 1, l_whence = 0, l_start = 0, l_len = 0, l_pid = 0}
exclif = <optimized out>
__func__ = "main"
(gdb)
Cleaner that way
Hello.
If you have some network devices, like Cisco Nexus and ports are connected into FEXes, you have incorrect output from ladvd, if it calls via pssh/ssh/ansible command and can lead to incorrect port shutdown/up.
Examples: http://www.panooo.com/DevOps_memo1 (can be translated via google translate).
And our issue:
>ssh ed-mgmt-1 'ladvdc -L'
Capability Codes:
r - Repeater, B - Bridge, H - Host, R - Router, S - Switch,
W - WLAN Access Point, C - DOCSIS Device, T - Telephone, O - Other
Device ID Local Intf Proto Hold-time Capability Port ID
ed-n5596-fe-2 eno4 LLDP 100 B Eth110/1/3
ed-n5596-fe-1 eno2 LLDP 115 B Eth110/1/3
ed-n5596-be-1 eno1 LLDP 107 B Eth110/1/3
ed-n5596-be-2 eno3 LLDP 106 B Eth110/1/3
> ssh ed-mgmt-1
[root@ed-mgmt-1 ~]# ladvdc -L
Capability Codes:
r - Repeater, B - Bridge, H - Host, R - Router, S - Switch,
W - WLAN Access Point, C - DOCSIS Device, T - Telephone, O - Other
Device ID Local Intf Proto Hold-time Capability Port ID
ed-n5596-fe-2 eno4 LLDP 117 B Eth110/1/31
ed-n5596-fe-1 eno2 LLDP 102 B Eth110/1/31
ed-n5596-be-1 eno1 LLDP 94 B Eth110/1/31
ed-n5596-be-2 eno3 LLDP 93 B Eth110/1/31
it caused that default width is 80 symbols (src/cli.c, #define TERM_DEFAULT 80), but it doesn't fit if Cisco Nexus is used.
How can you suggest to avoid this behaviour ?
Several distributions seem to be shipping snapshots of Git or last release + patches.
Please generate a new official release to standardize what distributions have.
With latest trunk:
+ make -j6
Making all in src
make[1]: Entering directory `/builddir/build/BUILD/ladvd-1.0.5/src'
make all-am
make[2]: Entering directory `/builddir/build/BUILD/ladvd-1.0.5/src'
CC compat/vis.lo
CC child.lo
CC master.lo
CC cli.lo
CC util.lo
CC sysinfo.lo
cc1: warnings being treated as errors
master.c: In function 'master_socket':
master.c:561: error: implicit declaration of function 'pcap_create'
master.c:561: error: assignment makes pointer from integer without a cast
master.c:565: error: implicit declaration of function 'pcap_set_timeout'
master.c:568: error: implicit declaration of function 'pcap_set_snaplen'
master.c:576: error: implicit declaration of function 'pcap_activate'
make[2]: *** [master.lo] Error 1
make[2]: *** Waiting for unfinished jobs....
Centos 5 libpcap version is 0.9.4
As you wrote at documentation I've installed
aptitude install autoconf automake pkgconfig libtool
And ran:
autoreconf -fi
libtoolize: putting auxiliary files in `.'.
libtoolize: copying file `./ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
libtoolize: copying file `m4/libtool.m4'
libtoolize: copying file `m4/ltoptions.m4'
libtoolize: copying file `m4/ltsugar.m4'
libtoolize: copying file `m4/ltversion.m4'
libtoolize: copying file `m4/lt~obsolete.m4'
configure.ac:66: error: possibly undefined macro: AC_SUBST
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
configure.ac:114: error: possibly undefined macro: AC_CHECK_LIB
configure.ac:133: error: possibly undefined macro: AC_CHECK_HEADERS
autoreconf: /usr/bin/autoconf failed with exit status: 1
How can I fix it? Ubuntu 14.04, thanks.
I'm testing with FreeNAS 11 (FreeBSD 11) and ladv and I was wondering why my switches weren't getting any neighbor information.
After running manually I found this:
root@store01:~ # ladvd -o -L -f -vvv child_init: ladvd 1.1.0 running child_send: fetching all interfaces netif_fetch: skipping interface ix0 netif_fetch: skipping interface ix1 netif_fetch: found ethernet interface igb0 netif_fetch: skipping interface igb0 (down) netif_fetch: found ethernet interface igb1 netif_fetch: skipping interface igb1 (down) netif_fetch: found ethernet interface igb2 netif_fetch: skipping interface igb2 (down) netif_fetch: found ethernet interface igb3 netif_fetch: skipping interface igb3 (down) netif_fetch: skipping interface lo0 netif_fetch: found bond interface lagg0 netif_fetch: adding interface lagg0 netif_fetch: detecting lagg0 settings netif_fetch: fetching addresses for all interfaces netif_iter: skipping interface lagg0 parent_signal: child exited with return code 0 parent_signal: quitting root@store01:~ #
I checked the source of netif.c and it only checks if there is a AF_INET address on a interface.
In my case lagg0 only has a IPv6 address:
root@store01:~ # ifconfig lagg0 lagg0: flags=8843 metric 0 mtu 1500 options=e407bb ether ac:1f:6b:2c:31:76 inet6 fe80::ae1f:6bff:fe2c:3176%lagg0 prefixlen 64 scopeid 0x8 inet6 2a05:1500:XX:YY:ae1f:6bff:fe2c:3176 prefixlen 64 autoconf nd6 options=23 media: Ethernet autoselect status: active groups: lagg laggproto lacp lagghash l2,l3,l4 laggport: ix0 flags=1c laggport: ix1 flags=1c root@store01:~ #
I added another ethernet interface to my machine and I couldn't for the life me work out why ladvd wasn't handling CDP packets until I ran wireshark. I discovered the new interface had FCS enabled, encapsulating an additional 4 bytes at the end of the frame.
I have located in your code where the packet gets rejected. Function: cdp_decode
in cdp.c
Line 384: the my_log
call will output "Corrupt CDP packet: invalid TLV length".
I tested this by manually increasing the overall packet length by 4 bytes (where then subtracted from "length") on line 376. It's as if it knows the packet length but trims off the FCS when parsing it.
Would you be able to fix or point me in the right direction?
I'm going to spend some time on it, I'll keep you posted but looking at your CV your have a ton of experience on network coding.
We are have issues (again) :)
Situation is the next. on Centos 7 from inactive link CDP packets are going with SRC MAC of teaming instead '00:00:00:00:00:00' how it was at Centos 5. It cause that Cisco learns MAC address on inactive interface and networking became unstable.
We have pcaps, if you need it.
What steps will reproduce the problem?
What is the expected output? What do you see instead?
We should see only physical links, not teaming
What version of the product are you using? On what operating system?
1.0.4, Centos 7.
Settings for teaming:
[root@ed-mgmt-3 src]# teamnl bond0 options
queue_id (port:eno1) 0
priority (port:eno1) 0
user_linkup_enabled (port:eno1) false
user_linkup (port:eno1) true
enabled (port:eno1) true
queue_id (port:eno3) 0
priority (port:eno3) 0
user_linkup_enabled (port:eno3) false
user_linkup (port:eno3) true
enabled (port:eno3) true
mcast_rejoin_interval 0
mcast_rejoin_count 0
notify_peers_interval 0
notify_peers_count 0
mode roundrobin
After starting with mapping to physical interfaces (eno1, eno2, eno3, eno4):
[root@ed-mgmt-3 src]# ./ladvdc -C
Capability Codes:
r - Repeater, B - Bridge, H - Host, R - Router, S - Switch,
W - WLAN Access Point, C - DOCSIS Device, T - Telephone, O - Other
Device ID Local Intf Proto Hold-time Capability Port ID
ed-n5596up-fe-1 eno2 CDP 28 S Eth110/1/31
ed-n5596up-be-2 eno3 CDP 28 S Eth110/1/31
ed-n5596up-fe-2 eno4 CDP 28 S Eth110/1/31
ed-n5596up-be-1 eno1 CDP 47 S Eth110/1/31
[root@ed-mgmt-3 src]# ./ladvdc -C
Capability Codes:
r - Repeater, B - Bridge, H - Host, R - Router, S - Switch,
W - WLAN Access Point, C - DOCSIS Device, T - Telephone, O - Other
Device ID Local Intf Proto Hold-time Capability Port ID
[root@ed-mgmt-3 src]# ./ladvdc -C
Cisco devices is receiving notifications.
After starting with default parameters (ladvd -aL):
[root@ed-mgmt-3 src]# ./ladvdc -C
Capability Codes:
r - Repeater, B - Bridge, H - Host, R - Router, S - Switch,
W - WLAN Access Point, C - DOCSIS Device, T - Telephone, O - Other
Device ID Local Intf Proto Hold-time Capability Port ID
ed-n5596up-be-2 eno3 CDP 22 S Eth110/1/31
ed-n5596up-fe-1 bond1 CDP 52 S Eth110/1/31
ed-n5596up-fe-1 eno2 CDP 112 S Eth110/1/31
ed-n5596up-be-1 eno1 CDP 172 S Eth110/1/31
ed-n5596up-be-1 bond0 CDP 142 S Eth110/1/31
[root@ed-mgmt-3 src]# ./ladvdc -C
Capability Codes:
r - Repeater, B - Bridge, H - Host, R - Router, S - Switch,
W - WLAN Access Point, C - DOCSIS Device, T - Telephone, O - Other
Device ID Local Intf Proto Hold-time Capability Port ID
ed-n5596up-fe-1 eno2 CDP 59 S Eth110/1/31
ed-n5596up-be-1 eno1 CDP 179 S Eth110/1/31
ed-n5596up-be-1 bond0 CDP 89 S Eth110/1/31
As you see, where is random interfaces go in and out from this.
I suppose, it should be fixed as it was for bond in Centos 5.
make libcheckwrap.la check_compat check_proto check_util check_tlv check_master check_child check_cli
make[2]: Entering directory `/builddir/build/BUILD/ladvd-1.0.5/tests'
CC check_wrap.lo
CCLD libcheckwrap.la
CC check_compat.o
CCLD check_compat
CC check_proto.o
CCLD check_proto
CC check_util.o
CCLD check_util
CC check_tlv.o
CCLD check_tlv
CC check_master.o
CCLD check_master
CC check_child.o
CCLD check_child
CC check_cli.o
CCLD check_cli
make[2]: Leaving directory `/builddir/build/BUILD/ladvd-1.0.5/tests'
make check-TESTS
make[2]: Entering directory `/builddir/build/BUILD/ladvd-1.0.5/tests'
make[3]: Entering directory `/builddir/build/BUILD/ladvd-1.0.5/tests'
PASS: check_compat
PASS: check_proto
FAIL: check_util
PASS: check_tlv
PASS: check_master
PASS: check_child
PASS: check_cli
make[4]: Entering directory `/builddir/build/BUILD/ladvd-1.0.5/tests'
make[4]: Nothing to be done for `all'.
make[4]: Leaving directory `/builddir/build/BUILD/ladvd-1.0.5/tests'
============================================================================
Testsuite summary for ladvd 1.0.4
============================================================================
# TOTAL: 7
# PASS: 6
# SKIP: 0
# XFAIL: 0
# FAIL: 1
# XPASS: 0
# ERROR: 0
============================================================================
See tests/test-suite.log
Please report to [email protected]
============================================================================
make[3]: Leaving directory `/builddir/build/BUILD/ladvd-1.0.5/tests'
make[2]: Leaving directory `/builddir/build/BUILD/ladvd-1.0.5/tests'
make[1]: Leaving directory `/builddir/build/BUILD/ladvd-1.0.5/tests'
RPM build errors:
Removing protocols from the build is desirable for embedded situations where memory usage should be minimised. Michel Stam has supplied patches to accomplish this.
You are saying in documentation, that you need run ./configure for compile. But here is only configure.ac file.
Is it normal or instructions should be expanded?
Would be very useful if one could exclude certain interfaces with a commandline flag from every being candidate to transmit a packet on, this flag is particularly useful in combination with -C, -L -E, -F or -N on boxes connected to an internet exchange.
I propose that the following:
ladvd -a -z -L -e em0 -e em1
will transmit LLDP packets on all interfaces in the system, except em0 and em1, even if it would receive a neighbor discovery packet on em0 and em1 (so -a does not apply to em0 and em1)
Hello.
As I remember, you have said, that releases file should contain all needed files for build.
I've taken it from https://github.com/sspans/ladvd/releases, but I got
+ ./configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu --program-prefix= --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info --docdir=/usr/share/doc/ladvd
/var/tmp/rpm-tmp.tqAwiH: line 38: ./configure: No such file or directory
Probably we or you need to do something?
Can you help me with preparing this environment in future?
Thank you.
Under FreeBSD, the following line in src/sysinfo.c does not correctly truncate the SMBIOS system serial number to LLDP_INVENTORY_SIZE.
kenv(KENV_GET, "smbios.system.serial", hinv->serial_number, len)
The serial number from kenv can be longer than LLDP_INVENTORY_SIZE, which
means the above approach to truncating it loses the null terminator. This
causes the serial number and manufacturer to be concatenated together in
the resulting TLV in the packet. Certain LLDP agents will panic when receiving a packet where the inventory size is exceeded.
The following patch addressed my immediate problem, but obviously the same issue exists with similar uses of kenv
(e.g. smbios.bios.version), so I have included it below instead of submitting a pull request. There is probably a better way to correctly truncate the string for all cases.
--- src/sysinfo.c.orig 2019-06-05 15:29:53 UTC
+++ src/sysinfo.c
@@ -218,6 +218,11 @@ void sysinfo_fetch(struct my_sysinfo *sysinfo) {
kenv(KENV_GET, "smbios.system.version", hinv->hw_revision, len);
kenv(KENV_GET, "smbios.bios.version", hinv->fw_revision, len);
kenv(KENV_GET, "smbios.system.serial", hinv->serial_number, len);
+ // The serial number from kenv can be longer than LLDP_INVENTORY_SIZE, which
+ // means the above approach to truncating it loses the null terminator. This
+ // causes the serial number and manufacturer to be concatenated together in
+ // the resulting TLV in the packet.
+ hinv->serial_number[LLDP_INVENTORY_SIZE] = '\0';
kenv(KENV_GET, "smbios.system.maker", hinv->manufacturer, len);
kenv(KENV_GET, "smbios.system.product", hinv->model_name, len);
#endif /* HAVE_KENV_H */
@@ -304,4 +309,5 @@ void sysinfo_forwarding(struct my_sysinfo *sysinfo) {
}
#endif
}
+
make check failed with a lot of warnings.
https://gist.github.com/sharewax/265009bdc5c178f43d3f81c35d68cfae
on Centos7 all checks works ok:
+ umask 022
+ cd /builddir/build/BUILD
+ cd ladvd-1.1.2
+ make check
Making check in src
make[1]: Entering directory `/builddir/build/BUILD/ladvd-1.1.2/src'
make[1]: Leaving directory `/builddir/build/BUILD/ladvd-1.1.2/src'
Making check in .
make[1]: Entering directory `/builddir/build/BUILD/ladvd-1.1.2'
make[1]: Nothing to be done for `check-am'.
make[1]: Leaving directory `/builddir/build/BUILD/ladvd-1.1.2'
Making check in doc
make[1]: Entering directory `/builddir/build/BUILD/ladvd-1.1.2/doc'
make[1]: Nothing to be done for `check'.
make[1]: Leaving directory `/builddir/build/BUILD/ladvd-1.1.2/doc'
Making check in systemd
make[1]: Entering directory `/builddir/build/BUILD/ladvd-1.1.2/systemd'
make[1]: Nothing to be done for `check'.
make[1]: Leaving directory `/builddir/build/BUILD/ladvd-1.1.2/systemd'
Making check in tests
make[1]: Entering directory `/builddir/build/BUILD/ladvd-1.1.2/tests'
make libcheckwrap.la check_compat check_proto check_util check_tlv check_parent check_child check_cli
make[2]: Entering directory `/builddir/build/BUILD/ladvd-1.1.2/tests'
CC check_wrap.lo
CCLD libcheckwrap.la
CC check_compat.o
CCLD check_compat
CC check_proto.o
CCLD check_proto
CC check_util.o
CCLD check_util
CC check_tlv.o
CCLD check_tlv
CC check_parent.o
CCLD check_parent
CC check_child.o
CCLD check_child
CC check_cli.o
CCLD check_cli
make[2]: Leaving directory `/builddir/build/BUILD/ladvd-1.1.2/tests'
make check-TESTS
make[2]: Entering directory `/builddir/build/BUILD/ladvd-1.1.2/tests'
make[3]: Entering directory `/builddir/build/BUILD/ladvd-1.1.2/tests'
PASS: check_compat
PASS: check_proto
PASS: check_util
PASS: check_tlv
PASS: check_parent
PASS: check_child
PASS: check_cli
make[4]: Entering directory `/builddir/build/BUILD/ladvd-1.1.2/tests'
make[4]: Nothing to be done for `all'.
make[4]: Leaving directory `/builddir/build/BUILD/ladvd-1.1.2/tests'
============================================================================
Testsuite summary for ladvd 1.1.2
============================================================================
# TOTAL: 7
# PASS: 7
# SKIP: 0
# XFAIL: 0
# FAIL: 0
# XPASS: 0
# ERROR: 0
============================================================================
make[3]: Leaving directory `/builddir/build/BUILD/ladvd-1.1.2/tests'
make[2]: Leaving directory `/builddir/build/BUILD/ladvd-1.1.2/tests'
make[1]: Leaving directory `/builddir/build/BUILD/ladvd-1.1.2/tests'
+ exit 0
Currently there are two socketpairs, one used for requests and one for messages.
These can be merged and switched over to openbsd's imsg.
This will require major refactoring of the ladvd internals, which is why I'd like to do it.
The goal is to make all messaging fully async.
I've modified output as below, created defs in the headers and also added code to cdp.c to add the values to the struct msg. At runtime I get no output what so ever when I run 'ladvdc -b eth0'.
I'm new to Cpp and was hoping you could point me in the right direction.
printf("INTERFACE_%u='%s'\n", count, STR(msg->name));
printf("HOSTNAME_%u='%s'\n", count, STR(peer_host));
printf("PLATFORM_%u='%s'\n", count, STR(peer_platform));
printf("PORTNAME_%u='%s'\n", count, STR(peer_portname));
printf("PORTDESCR_%u='%s'\n", count, STR(peer_portdescr));
printf("DUPLEX_%u='%s'\n", count, STR(peer_duplex));
printf("PROTOCOL_%u='%s'\n", count, protos[msg->proto].name);
printf("ADDR_INET4_%u='%s'\n", count, STR(msg->peer[PEER_ADDR_INET4]));
printf("ADDR_INET6_%u='%s'\n", count, STR(msg->peer[PEER_ADDR_INET6]));
printf("ADDR_802_%u='%s'\n", count, STR(msg->peer[PEER_ADDR_802]));
printf("VLAN_ID_%u='%s'\n", count, STR(msg->peer[PEER_VLAN_ID]));
printf("CAPABILITIES_%u='%s'\n", count, STR(cap));
printf("TTL_%u='%" PRIu16 "'\n", count, msg->ttl);
printf("HOLDTIME_%u='%" PRIu16 "'\n", count, holdtime);
Hello,
There is only one implementation of an LLTD responder for Linux (provided by Microsoft, buggy and lacking in features) and none for FreeBSD and I believe it would be useful for embedded routers running these OSes.
Please consider adding support for this protocol in the ladvd daemon.
Thanks
P.S. More info:
http://en.wikipedia.org/wiki/Link_Layer_Topology_Discovery
Organization specific TLV (127), length 8: OUI ANSI/TIA (0x0012bb)
Network policy Subtype (2)
Application type [voice] (0x01), Flags [Tagged]
Vlan id 100, L2 priority 6, DSCP value 46
it would be useful for testing/configuring ip phones from linux...
Reported by m.dilasser, Jan 20, 2013
In order to be seen in Mikrotik devices, ladvd have to announce CDP packets in version 1, in src/proto/cdp.h :
Maybe useful to have an option in command line to force version 1.
For Mikrotik devices :
Field 0x0C is the name of the board (RB450, RB433, etc ...)
Field 0x0B is the sofware-id
Here a discovery packet received on a Mikrotik :
0000 ff ff ff ff ff ff 00 0c 42 41 1b 20 08 00 45 00 ........ BA. ..E.
0010 00 76 00 00 40 00 40 11 e7 1d 0a 64 48 f6 ff ff .v..@.@. ...dH...
0020 ff ff 16 2e 16 2e 00 62 e6 f9 00 00 0f 73 00 01 .......b .....s..
0030 00 06 00 0c 42 41 1b 20 00 05 00 06 6d 6b 74 32 ....BA. ....mkt2
0040 30 32 00 07 00 04 35 2e 32 32 00 08 00 08 4d 69 02....5. 22....Mi
0050 6b 72 6f 54 69 6b 00 0a 00 04 ef 49 04 00 00 0b kroTik.. ...I....
0060 00 09 43 34 42 44 2d 4d 52 42 4d 00 0c 00 05 52 ..C4BD-M RBM....R
0070 42 34 33 33 00 0e 00 01 01 00 10 00 07 62 72 69 B433.... .....bri
0080 64 67 65 31 dge1
Nov 4 (44 hours ago) Delete comment
The protocol breaks when a port-channel is created, which I'm assuming is not expected? The threads below pretty much sum it up:
https://redmine.pfsense.org/issues/8139#change-36749
https://redmine.ixsystems.com/issues/27497
While I'm not sure if it's isolated to just FreeBSD 11, the bug is that LLDP completely breaks once a lag is activated. I definitely have not looked at the code, but I would assume that even with a LAGG, we could just keep sending the LLDP frames down the physical interfaces. From what it sounds like (from other threads, etc), the way FreeBSD handles the creation of the bond, those interfaces might disappear and that is no longer possible. If that's the case, at the very least, can we move the frames to transmit on the bond then? From the PFSense logs anyways, it looks like it's still trying to transmit on the physical interface. The following log is directly from my box right now:
Sep 8 15:02:02 ladvd interface ix1 is invalid
Sep 8 15:02:02 ladvd interface ix0 is invalid
Sep 8 15:01:32 ladvd interface ix1 is invalid
Sep 8 15:01:32 ladvd interface ix0 is invalid
Sep 8 15:01:02 ladvd interface ix1 is invalid
Sep 8 15:01:02 ladvd interface ix0 is invalid
Sep 8 15:00:32 ladvd interface ix1 is invalid
Sep 8 15:00:32 ladvd interface ix0 is invalid
Sep 8 15:00:02 ladvd interface ix1 is invalid
Sep 8 15:00:02 ladvd interface ix0 is invalid
Maybe the underlying issue is it's still looking for the physical interfaces, when they no longer exist?
In certain cases it's desirable to use the older non-pcap code to limit code-size and dependencies.
Michel Stam has supplied a patch to accomplish this.
Hello. I just wanted to build ladvd for Oracle Linux 9 (I suppose the issue will be present for any RHEL based 9 version).
The same issue as in debian based https://www.mail-archive.com/[email protected]/msg598937.html
Log is here: https://gist.github.com/sharewax/568a34cbf9b6f79aa34d2b0cb68e6fef
All is building ok with Centos7 (gcc 4.5).
GCC on OL9 is 11
Hello,
we have tried ladvd 1.1.0 on our systems (no link aggregation, active/standby ports or whatever) but most of the times ladvdc doesnt return any information on any of the interfaces on the systems, sometimes it just returns info for eth0, and in very rare occasions it returns information on all the NICs.
The current model isn't very flexible and doesn't meet the lldp(-med) requirements. With the new child_send it now is possible to generate
packets for individual interfaces, which in turn makes it possible to be a lot more flexible with other parts of the code.
Hello. Tried with latest commit e85d442:
~/ladvd/src# ./ladvd -f -vvv -a
child_init: ladvd 1.0.4 running
child_send: fetching all interfaces
netif_fetch: skipping interface lo
netif_fetch: found ethernet interface eth0
netif_fetch: adding interface eth0
netif_fetch: found ethernet interface eth1
netif_fetch: adding interface eth1
netif_fetch: found ethernet interface eth2
netif_fetch: adding interface eth2
netif_fetch: found ethernet interface eth3
netif_fetch: adding interface eth3
netif_fetch: found ethernet interface eth4
netif_fetch: skipping interface eth4 (down)
netif_fetch: found ethernet interface eth5
netif_fetch: skipping interface eth5 (down)
netif_fetch: found bond interface bond0
netif_fetch: adding interface bond0
netif_fetch: found bond interface bond1
netif_fetch: adding interface bond1
netif_fetch: detecting eth0 settings
netif_fetch: detecting eth1 settings
netif_fetch: detecting eth2 settings
netif_fetch: detecting eth3 settings
netif_fetch: detecting bond0 settings
netif_bond: found slave eth0
netif_bond: found slave eth2
netif_fetch: detecting bond1 settings
netif_bond: found slave eth1
netif_bond: found slave eth3
netif_fetch: fetching addresses for all interfaces
child_send: starting loop with interface bond0
child_send: fetching eth0 media details
netif_physical: autoneg supported on eth0
child_send: fetching eth2 media details
netif_physical: autoneg supported on eth2
child_send: starting loop with interface bond1
child_send: fetching eth1 media details
netif_physical: autoneg supported on eth1
child_send: fetching eth3 media details
netif_physical: autoneg supported on eth3
So doesn't see any package, but I have tcpdump with CDP and LLDP on this interfaces.
And the next error then trying to run:
~/ladvd/src# ./ladvd -f -vvv -C
child_init: ladvd 1.0.4 running
child_send: fetching all interfaces
netif_fetch: skipping interface lo
netif_fetch: found ethernet interface eth0
netif_fetch: adding interface eth0
netif_fetch: found ethernet interface eth1
netif_fetch: adding interface eth1
netif_fetch: found ethernet interface eth2
netif_fetch: adding interface eth2
netif_fetch: found ethernet interface eth3
netif_fetch: adding interface eth3
netif_fetch: found ethernet interface eth4
netif_fetch: skipping interface eth4 (down)
netif_fetch: found ethernet interface eth5
netif_fetch: skipping interface eth5 (down)
netif_fetch: found bond interface bond0
netif_fetch: adding interface bond0
netif_fetch: found bond interface bond1
netif_fetch: adding interface bond1
netif_fetch: detecting eth0 settings
netif_fetch: detecting eth1 settings
netif_fetch: detecting eth2 settings
netif_fetch: detecting eth3 settings
netif_fetch: detecting bond0 settings
netif_bond: found slave eth0
netif_bond: found slave eth2
netif_fetch: detecting bond1 settings
netif_bond: found slave eth1
netif_bond: found slave eth3
netif_fetch: fetching addresses for all interfaces
child_send: starting loop with interface bond0
child_send: fetching eth0 media details
netif_physical: autoneg supported on eth0
child_send: building CDP packet for eth0
child_send: sending CDP packet (260 bytes) on eth0
child_send: fetching eth2 media details
netif_physical: autoneg supported on eth2
child_send: building CDP packet for eth2
child_send: sending CDP packet (260 bytes) on eth2
child_send: starting loop with interface bond1
child_send: fetching eth1 media details
netif_physical: autoneg supported on eth1
child_send: building CDP packet for eth1
child_send: sending CDP packet (260 bytes) on eth1
child_send: fetching eth3 media details
netif_physical: autoneg supported on eth3
child_send: building CDP packet for eth3
child_send: sending CDP packet (260 bytes) on eth3
child_cli_accept: cli connection failed
child_cli_accept: cli connection failed
child_cli_accept: cli connection failed
child_cli_accept: cli connection failed
child_cli_accept: cli connection failed
child_cli_accept: cli connection failed
child_cli_accept: cli connection failed
child_cli_accept: cli connection failed
child_cli_accept: cli connection failed
child_cli_accept: cli connection failed
child_cli_accept: cli connection failed
child_cli_accept: cli connection failed
child_cli_accept: cli connection failed
child_cli_accept: cli connection failed
child_cli_accept: cli connection failed
child_cli_accept: cli connection failed
child_cli_accept: cli connection failed
child_cli_accept: cli connection failed
child_cli_accept: cli connection failed
child_cli_accept: cli connection failed
child_cli_accept: cli connection failed
child_cli_accept: cli connection failed
child_cli_accept: cli connection failed
child_cli_accept: cli connection failed
child_cli_accept: cli connection failed
child_cli_accept: cli connection failed
child_cli_accept: cli connection failed
child_cli_accept: cli connection failed
child_cli_accept: cli connection failed
child_cli_accept: cli connection failed
child_cli_accept: cli connection failed
child_cli_accept: cli connection failed
child_cli_accept: cli connection failed
child_cli_accept: cli connection failed
child_cli_accept: cli connection failed
child_cli_accept: cli connection failed
child_cli_accept: cli connection failed
child_cli_accept: cli connection failed
child_cli_accept: cli connection failed
child_cli_accept: cli connection failed
child_cli_accept: cli connection failed
child_cli_accept: cli connection failed
child_cli_accept: cli connection failed
child_cli_accept: cli connection failed
child_cli_accept: cli connection failed
child_cli_accept: cli connection failed
child_cli_accept: cli connection failed
child_cli_accept: cli connection failed
child_cli_accept: cli connection failed
child_cli_accept: cli connection failed
child_cli_accept: cli connection failed
child_cli_accept: cli connection failed
child_cli_accept: cli connection failed
child_cli_accept: cli connection failed
And flooods a lot.
Reported by @rfc1036
Current behaviour:
Desired behaviour:
Suggested fixes:
HI,
Just wanted to know the possibility to query about neighbour information in ladvd.
I suppose there should be updated ladvd.spec for Centos 7 to support systemd.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.