LLDP or DSA bug on mt7621

Hi

i have strange problem with LLDP on cudy wr1300

config device
        option type 'bridge'
        option name 'switch'
        list ports 'lan1'
        list ports 'lan2'
        list ports 'lan3'
        list ports 'lan4'
        list ports 'wan'

config bridge-vlan
        option device 'switch'
        option vlan '1'
        list ports 'wan:u*'
...

If i set LLDP to
configure system interface pattern wan
OWRT "see" the managed switch, tested with lldpctl
so far so good
but, managed switch does NOT ! "see" OWRT

then i tested with
configure system interface pattern switch.1
vlan1 is untagged on WAN port
this time, managed switch "see" OWRT as interface switch.1
but OWRT does not "see" managed switch

workaround is to set both
configure system interface pattern wan, switch.1
so both managed switch and OWRT see each other
but it is partly incorrect because managed switch will list neighbor port as "switch.1" instead of WAN :frowning:

lastly, i am tested same config on HAP AC2 (ipq40xx) DSA and it is working as expected
configure system interface pattern wan
work in both direction

is it LLDP or DSA bug ?
i really need correct LLDP info on both side

tried also with
MikroTik RouterBOARD M33G / mt7621
same thing
only this config work which produce incorrect result

cat /etc/lldpd.d/lldpd.conf 
...
configure system interface pattern switch.1,wan
...

all 3 device tested on

DISTRIB_RELEASE='23.05-SNAPSHOT'
DISTRIB_REVISION='r23400-104178a990'
DISTRIB_TARGET='ramips/mt7621'

Seems like it could be a combination of both.

It's not impossible that the device interfaces defined in the DTS are in the wrong order somehow.

@marek22k Perhaps you have some ideas?

Hello,

at first sight the following comes to my mind:
is there a specific reason why you configure lldpd directly and not go through UCI? If you use lldpd directly, make sure that UCI does not overwrite the lldpd configuration file or add anything supplementary?

To analyze the situation in more detail, I'm always a friend of tcpdump (or similar to tshark). With this you can see quite easily if the error is on the lldp software (and if so, on which side) or not.

To filter lldp traffic with tcpdump, you can use the following command:

tcpdump -i [interface] ether proto 0x88cc

found at https://stackoverflow.com/questions/18095812/capture-lldp-packets-using-tcpdump.

Furthermore, you should look at how lldpd is set. If you want to support lldp, lldp must be started with -l. If you want to force lldp (lldpd should also send packets if no other lldp device is found), lldp must be started with -ll.

To better understand your setup: You have two Ethernet and LLDP capable devices, both of which are connected to each other. Device 1 is OpenWrt and there is a bridge configured between multiple ports. On the bridge is again a VLAN. Device 2 is connected to one of the ports of the bridge and also has the same VLAN configured. Device 2 is your other lldp enabled device. Did I understand that correctly? Then you could also start lldpd with "-C [VLAN Interface]".

Furthermore, if I remember correctly, I noticed that lldpctl tends to hide things if you ask too unspecifically, unless you set the output to json. You could try the following commands:

lldpcli -f json0 show [statistics|neighbors details|interfaces|chassis]

I hope I could help you a little further.

Hi marek
lets start from beginning

because i have no will to fight with UCI options for this config:

cat /etc/lldpd.d/lldpd.conf 
configure lldp portidsubtype ifname
configure system interface pattern wan
configure system description 'OpenWRT_23.05'
configure system hostname 'wr103.wrt.XXXXX'
unconfigure system interface description
configure ports wan lldp custom-tlv add oui 00,80,c2 subtype 1 oui-info '00,01'
configure system ip management pattern 169.254.3.103,fd00:3:255::103

no, it will not :slight_smile:
custom image, only DumbAP, no fancy things, and yes, SNMP and LLDP startup scripts are replaced

we are using some Cisco and/or Eltex switches to distribute vlans
on these managed switches are connected fleet of DumbAPs
DumpAPs have purpose of serving vlans on WIFI with vlan per passphrase setup
so, i don't want to sound rude, but, yes, we have enough experience with network equipment

to cut things short
LLDP is working as expected on

  1. Bare metal
  2. ProxMox
  3. IPQ40xx

i prefer DSA architecture (or straight ethX) because we use LibreNMS for monitoring, and yes, i need to see per port status/statistics which is impossible with 'swconfig' device

it does NOT work with any mt7621 device i have at the moment
RB 760igs, cudy wr1300 v3, RB M33G, RB750GR3

ok, it is working, but not as expected :slightly_frowning_face:

it is never !! problem how OWRT show info from lldpcli/snmp
it is always correct

for ex:

LLDP neighbors:
-------------------------------------------------------------------------------
Interface:    wan, via: LLDP, RID: 1, Time: 0 day, 18:02:34
  Chassis:     
    ChassisID:    mac XX:XX:XX:68:2a:d7
    SysName:      sw35.netdev.XXXXX

it is always problem on managed switch side which will show "switch.1" which is wrong

lldpd is started on every device with above config (yes, i need custom TLVs, yes i need IPv6 mgmn address listed)
with this command line
/usr/sbin/lldpd -d -l -O /var/etc/lldpd.d/lldpd.conf -x -X /var/run/agentx.sock -L /usr/sbin/lldpcli

will setup tcpdump between OWRT and managed switch in next few days when i have time

example config ....

cat /etc/config/network 

config device
        option type 'bridge'
        option name 'switch'
        list ports 'lan1'
        list ports 'lan2'
        list ports 'lan3'
        list ports 'lan4'
        list ports 'wan'
        option ipv6 '0'

config bridge-vlan
        option device 'switch'
        option vlan '1'
        list ports 'wan:u*'

config bridge-vlan
        option device 'switch'
        option vlan '2'
        list ports 'wan:t'

config bridge-vlan
        option device 'switch'
        option vlan '19'
        list ports 'wan:t'

config bridge-vlan
        option device 'switch'
        option vlan '100'
        list ports 'wan:t'
        list ports 'lan3:u*'
        list ports 'lan4:u*'

config bridge-vlan
        option device 'switch'
        option vlan '200'
        list ports 'wan:t'
        list ports 'lan1:u*'
        list ports 'lan2:u*'

config bridge-vlan
        option device 'switch'
        option vlan '255'
        list ports 'wan:t'

config interface 'vlan1'
         option device 'switch.1'
        option proto 'none'
        option ipv6 '0'

config interface 'vlan2'
        option proto 'none'
        option device 'switch.2'
        option ipv6 '0'

config interface 'vlan19'
        option proto 'none'
        option device 'switch.19'
        option ipv6 '0'

config interface 'vlan100'
        option proto 'none'
        option device 'switch.100'
        option ipv6 '0'

config interface 'vlan200'
        option proto 'none'
        option device 'switch.200'
        option ipv6 '0'

config interface 'vlan255'
        option proto 'static'
        option device 'switch.255'
        option ipaddr '169.254.2.111/24'
        option ip6addr 'fd00:2:255::111/64'
        option gateway '169.254.2.1'
        option dns '169.254.2.1'
        option ip6gw 'fd00:2:255::1'
config wifi-device 'radio0'
        option type 'mac80211'
        option path '1e140000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0'
        option channel '1'
        option band '2g'
        option htmode 'HT20'
        option cell_density '0'
        option country 'HU'
        option disabled '0'
        option noscan '1'
        option legacy_rates '0'
        option distance 'auto'
        option txpower '14'

config wifi-device 'radio1'
        option type 'mac80211'
        option path '1e140000.pcie/pci0000:00/0000:00:01.0/0000:02:00.0'
        option channel '116'
        option band '5g'
        option htmode 'VHT40'
        option disabled '0'
        option legacy_rates '0'
        option distance 'auto'
        option country 'PA'
        option noscan '1'
        option txpower '23'

config wifi-iface 'wifinet0'
        option device 'radio0'
        option mode 'ap'
        option network 'vlan2'
        option ssid 'test-AP'
        option key 'test-guest'
        option encryption 'psk2'
        option wmm '1'
        option short_preamble '1'
        option disassoc_low_ack '0'
        option max_inactivity '120'
        option isolate '1'
        option disabled '0'
        option ifname 'wlan0'
        option multicast_to_unicast_all '1'
        option macaddr '0e:02:02:00:01:11'

config wifi-iface 'wifinet1'
        option device 'radio1'
        option mode 'ap'
        option network 'vlan2'
        option ssid 'test-AP'
        option key 'test-guest'
        option encryption 'psk2'
        option wmm '1'
        option short_preamble '1'
        option disassoc_low_ack '0'
        option max_inactivity '120'
        option isolate '1'
        option disabled '0'
        option ifname 'wlan1'
        option multicast_to_unicast_all '1'
        option macaddr '0e:02:02:01:01:11'

config wifi-vlan
        option name 'vl100'
        option network 'vlan100'
        option vid '100'

config wifi-station
        option key 'test100-prn'
        option vid '100'

config wifi-vlan
        option name 'vl200'
        option network 'vlan200'
        option vid '200'

config wifi-station
        option key 'test200-lan'
        option vid '200'

hi to all

looks like i nailed it :smiley:
tested so far on MikroTik_RouterBOARD_M33G

here is a commit which put WAN port to gmac1

and if i revert it, put back WAN to switch0

		port@0 {
			status = "okay";
			label = "wan";
		};

everything is OK
LLDP with
configure system interface pattern wan
works as expected

will try tomorrow on cudy wr1300

@arinc9
since it is your commit ... do you have any idea how to solve this ?

I could confirm that LLDP work on WAN port with reverting gmac1 patch for cudy wr1300 v2/v3

<                 port@4 {
<                         status = "okay";
<                         label = "wan";
<                         nvmem-cells = <&macaddr_bdinfo_de00>;
<                         nvmem-cell-names = "mac-address";
<                         mac-address-increment = <1>;
<                 };

I guess that makes sense if this is used in light of that git diff:

@marek22k Is there anything in your LUCI GUI that cannot handle what is here?:

Yes, unfortunately:
There is no way to configure portidsubtype in the GUI. Furthermore, the settings in the GUI are created "globally" and applied to every port where LLDP is activated. Furthermore, the GUI cannot handle custom-tlv.

I don't see the GitHub issue related to this post posted here, so I have posted my response to it below. I can't reproduce the issue, and the user has not yet responded to set up the device with the commands I've provided. This makes me believe the issue arises from bad user configuration, and my muxing patch is being blamed in a lazy attempt to find a scapegoat. I've had this happen with another user who also claimed that reverting the patch fixed their issue, which actually didn't.

Hi @arinc9

do you really wrote this ?
did you read the whole github issue ?
did i was lazy to provide results ?
did i tried out patches provided by ptpt52 ?

yes, everything is done, except, i did not response to your last observation that you tried LLDP against other linux machine

should i reply you in same manner ?
a lazy attempt to skip tryout with real network equipment like managed switch ?
plese, dont use these tipe of words, OK ?

as from my point of view, reverting GMAC patch work ok 4 type of mt7621 device out on field with LLDP and eltex/cisco/jetstream switches

have a nice day

Hi @NPeca75. First of all, I feel flattered of your prompt response. If only you had done the same for the steps I've provided to you to test, we would have made some progress.

I believe I have read the whole GitHub issue, hence my providing of steps for you to test. From my point of view, you haven't done anything I've requested from you.

From what I can see, you still haven't tried receiving LLDP frames on a Linux machine. So what makes you believe that, on your side, LLDP frames would be properly received on a Linux machine but not on these proprietary switches that you speak of?

Could you also walk me through the thought process that you seem to have, where the LLDP frames being properly received on a Linux machine, but not on these switches, points to something being wrong with the device transmitting these frames instead of the switches receiving them?

These facts have led me to believe that you were lazily blaming your issue on something that did not cause it. Feel free to prove me wrong by doing the steps I've provided to you and respond with the results.

I'm not the OP, but I also have an issue with LLDP and the WAN port on 2 MT7621 devices, the Mir4A and the CudyWr1300. The peers of those devices are RTL838X switches running a recent OpenWrt snapshot.

Both MT7621 have LLDP-capable peers connected to WAN, WAN is used for batman. LAN1 on 1 the WR1300 is also connected to an LLDP-capable peer. The devices on the other ends of those 3 connections can see LLDP from the MT7621s on all 3 connections, but only the WR1300 sees the LLDP from the RTL838X, and there only on LANX., not on WAN.

So to me that sounds like: Reception of LLDP on WAN port of MT7621 seems to not work (at least) in (some) (of my desired) configurations.

$ ssh root@rtl838x lldpcli show running-configuration | grep Interface\ pattern:
  Interface pattern: lo,lan1,lan2,lan3,lan4,lan5,lan6,lan7,lan8
$ ssh root@mt7621 lldpcli show running-configuration | grep Interface\ pattern:
  Interface pattern: lo,wan,lan1,lan2

Probably related LLDP PDUs should not be forwarded in 802.1d but some devices are forwarding them - #3 by howels