add respondd-module-lldp

[genofire]

Could be usefull on wired networks (with a lot of switches) - to find the right neigbours.

[T-X]

Hi @genofire, is there some additional information somewhere how this package is improving things?

Also, there seem to be descriptions missing in the Makefile and some documentation for readthedocs seems missing, too.

[genofire]

It is just old code, which somebody maybe want.

It is possible to run a lldpd on the switch.
So the switch talk to each other independent from there (vlan-) configuration. And learn the real neighbours the interfaces (which is not possible with batman-adv or babel runs on all interface in the same vlan/switched)

https://github.com/FreifunkBremen/ffhb-packages/blob/0b856b1dc51521247cb2e0069f6621c6034b1737/ffhb-breminale/files/lib/gluon/upgrade/500-lldpd-config

Another solution is to create for every interface a vlan and let batman-adv and babel detect neighbours with there routing protocol - which use always there CPU.

[rubo77]

kannst du das noch mal auf deutsch erklären bitte?

Und was ist ein lldpd? wofür ist der gut?

[genofire]

Es ist alter code von uns, der vielleicht auch nicht gewollt ist. (Wollte es eher als Anregung zur Verfügung stellen.)

Es ist möglich den lldp-daemon für die integrierten Switches zu verwenden.
Mit dessen Hilfe unterhalten sich die Switche in den Knoten. Dies passiert unabhängig von den Konfiguration der VLANs, um Informationen von andere direkt angeschlossen Switche zu erhalten. So können die wirkliche Nachbarn direkt in Erfahrung gebracht werden.
(Das mit den Meshprotokollen z.B. Batman-adv oder Babel nicht möglich ist, wenn die interface des Switchen im selben VLAN hängen. So melden dir Meshprotokolle bei manchmal Knoten das sie direkte Nachbarn sind, obwohl ein Knoten mit seinen Switch dazwischen ist)

Eine Alternative Variante um reale Nachbarn zu sehen ist, das jedes Interface vom Switch als eigenes VLAN konfiguriert wird. Wodurch die Meshprotokoll die Nachbarn richtig erkennt. Doch dadurch durchläuft alles die CPU, was das Netz tendenziell wieder langsam macht.

[neocturne]

Memory leaks: conn must be released using lldpctl_release(), ifaces, port and neighbors using lldpctl_atom_dec_ref() (and possibly I'm overlooking further issues).

[genofire]

done

[neocturne]

ifaces and port are still leaking.

[rotanid]

@genofire what's the progress here, any updates on the remaining comments?

[genofire]

sry, i have no time to test it -> thats the reason, why i have not fixed it.

[rotanid]

@genofire have you fixed all the issues? they are marked as outdated, so maybe you have?

[genofire]

i though so - will test it end of next week again ...

[rotanid]

@genofire ?

[mweinelt]

I just tried this package on one of my nodes connected to a 2960G that emits both LLDP and CDP, which I both see arrive on eth1 which is a member to br-wan.

• Do I need a firewall rule for lldp to work? Because the lldpd is not registering any neighbors, not via lldpcli show neighbors nor via respondd ("lldp":{}").

• I don't see it emitting anything either, which would be even nicer for big setups. But I think that should be handled by a gluon-lldp package.

[genofire]

@mweinelt thank you for testing - do you have added the interface/switch to lldp?
I think uci set lldpd.config.interface 'eth0' should solve it (and a restart).

I have also found a pvid snippet in my history (for TP-Link TL-WDR3600 v1 and TP-Link Archer C7 v2):

-- Set PVID for ports
uci:delete_all('network', 'switch_port')
for i=0, 6, 1 do
    uci:section('network', 'switch_port', 'port_' .. i, {
        pvid = 1,
        port = i,
    })
end

[mweinelt]

Yep, that looks great now. To make this useful we'd need a gluon-lldp wrapper package that creates the config.

Unfortunately as soon as LLDP neighbors are present respondd crashes for me regularly when neighbors is queried.

Thu Apr  2 18:50:32 2020 daemon.info procd: Instance gluon-respondd::instance1 s in a crash loop 8 crashes, 9 seconds since last crash

Not too much info, but here it goes:

# /usr/bin/respondd -d /usr/lib/respondd -p 1001 -g ff02::2:1001 -i mesh0 -i mesh1 -i vx_mesh_wan -g ff05::2:1001 -i br-client -t 10
Segmentation fault

# lldpcli show neighbors
-------------------------------------------------------------------------------
LLDP neighbors:
-------------------------------------------------------------------------------
Interface:    eth1, via: LLDP, RID: 1, Time: 0 day, 00:07:21
  Chassis:     
    ChassisID:    mac 68:bd:ab:1c:6d:00
    SysName:      sw1.lossy.network
    SysDescr:     Cisco IOS Software, C2960 Software (C2960-LANBASEK9-M), Version 15.0(2)SE11, RELEASE SOFTWARE (fc3)
                  Technical Support: http://www.cisco.com/techsupport
                  Copyright (c) 1986-2017 by Cisco Systems, Inc.
                  Compiled Sat 19-Aug-17 09:34 by prod_rel_team
    MgmtIP:       192.168.42.253
    Capability:   Bridge, on
  Port:        
    PortID:       ifname Gi0/3
    PortDescr:    GigabitEthernet0/3
    TTL:          120
-------------------------------------------------------------------------------

Crahses roughly on the third neighbors query, all responses are empty.

[genofire]

No idea, how to write/fix it for all the router models ...
(it would be nice, if other person could write a soluntion - and i build somethink in yanic )

But let us take one step at once, and bring this respondd package upstream ;)

(do you need both? lldpd and network.switch_port)

[mweinelt]

But let us take one step at once, and bring this respondd package upstream ;)

Agreed.

[genofire]

I try it again - sadly, it crashes:

Sat Jul  9 21:36:18 2022 kern.info kernel: [15749.966321] do_page_fault(): sending SIGSEGV to respondd for invalid read access from 00000000
Sat Jul  9 21:36:18 2022 kern.info kernel: [15749.975196] epc = 00000000 in respondd[400000+5000]
Sat Jul  9 21:36:18 2022 kern.info kernel: [15749.980195] ra  = 77df2f2b in libjson-c.so.5.1.0[77dee000+1a000]

and

root@d46e0e366a3e:~# /usr/bin/respondd -d /usr/lib/respondd -p 1001 -g ff02::2:1001 -i eth1.100 -g ff05::2:1001 -i br-mgmt -t 10
Bus error

i will try to debug it next days -> or somebody has an idea for me, "yet".

[genofire]

@T-X found maybe a bugfix, so i have commit it. We should test/review this PR again ;)