realtek: rtl93xx: fix incorrect physical port selection #19802
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This comment was marked as resolved.
This comment was marked as resolved.
plappermaul
suggested changes
Aug 18, 2025
| @@ -153,7 +153,8 @@ static void rtl839x_create_tx_header(struct p_hdr *h, unsigned int dest_port, in | |||
| static void rtl930x_create_tx_header(struct p_hdr *h, unsigned int dest_port, int prio) | |||
| { | |||
| h->cpu_tag[0] = 0x8000; /* CPU tag marker */ | |||
| h->cpu_tag[1] = h->cpu_tag[2] = 0; | |||
| h->cpu_tag[1] = 0x0100; /* Set FWD_TYPE to PHYSICAL (1) */ | |||
There was a problem hiding this comment.
I fear that this will not play well with trunks (if we ever get them in place). Please check if logical (2) works the same for now.
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
There was a problem hiding this comment.
Btw. Sharadanand said that he has bonding + trunking working (afaik also with this patch applied). This has to be confirmed and double checked
This might be the case. The 1/2 difference I'm after is this:
There was a problem hiding this comment.
I'm not used to seeing LLDP undergo load-balancing when ports are trunked - doesn't LLDP still relate to the underlying physical port even if a trunk is created - that is the "link layer" in LLDP. LLDP has limited usefulness when troubleshooting LAG and MLAG installations if all you see if the trunk ID and not the underlying interface that is connected from the peer switch.
But maybe I am misunderstanding this, I am still going to build the change and test.
There was a problem hiding this comment.
Still working with 0x0200 instead of 0x0100 for cpu_tag[1] in these functions (testing on rtl930x device).
There was a problem hiding this comment.
As tiny as this change is ... The CPU port handling is tricky (e.g. https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=a22d359fa56fe06ebd74f87eccacf56b3752da58). So we should be sure if we
- can go for a one-config-fits-all-packets solution or
- if we must create headers per packet individually
Tests will tell.
| @@ -168,7 +169,8 @@ static void rtl930x_create_tx_header(struct p_hdr *h, unsigned int dest_port, in | |||
| static void rtl931x_create_tx_header(struct p_hdr *h, unsigned int dest_port, int prio) | |||
| { | |||
| h->cpu_tag[0] = 0x8000; /* CPU tag marker */ | |||
| h->cpu_tag[1] = h->cpu_tag[2] = 0; | |||
| h->cpu_tag[1] = 0x0100; /* Set FWD_TYPE to PHYSICAL (1) */ | |||
02a1f32 to
4c91e32
Compare
|
Final questions before approving this:
|
This comment was marked as resolved.
This comment was marked as resolved.
ecsv
approved these changes
Aug 18, 2025
plappermaul
approved these changes
Aug 18, 2025
When testing LLDP and STP, we observed that locally generated multicast packets (e.g. LLDP, STP) were not restricted to the designated output port(s). For example, when transmitting on `lan1`, the same packet was also forwarded to other ports such as `lan2`. Steps to reproduce: 1. Configure lldpd to use `lan1` in UCI and restart the service 2. Connect devices to `lan1` and `lan2` 3. Observe that the device on `lan2` still receives LLDP packets The issue was caused by an incorrect `FWD_TYPE` setting in the TX CPU TAG, which failed to enforce the selected egress port(s). Fix this by updating the TX CPU TAG to set `FWD_TYPE` correctly, ensuring that locally generated packets are transmitted only on the intended port(s). Signed-off-by: Issam Hamdi <ih@simonwunderlich.de> Link: openwrt#19802 Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
4c91e32 to
8c42e63
Compare
igor-dyatlov
pushed a commit
to igor-dyatlov/openwrt
that referenced
this pull request
Aug 26, 2025
When testing LLDP and STP, we observed that locally generated multicast packets (e.g. LLDP, STP) were not restricted to the designated output port(s). For example, when transmitting on `lan1`, the same packet was also forwarded to other ports such as `lan2`. Steps to reproduce: 1. Configure lldpd to use `lan1` in UCI and restart the service 2. Connect devices to `lan1` and `lan2` 3. Observe that the device on `lan2` still receives LLDP packets The issue was caused by an incorrect `FWD_TYPE` setting in the TX CPU TAG, which failed to enforce the selected egress port(s). Fix this by updating the TX CPU TAG to set `FWD_TYPE` correctly, ensuring that locally generated packets are transmitted only on the intended port(s). Signed-off-by: Issam Hamdi <ih@simonwunderlich.de> Link: openwrt#19802 Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Vladdrako
pushed a commit
to Vladdrako/openwrt
that referenced
this pull request
Aug 27, 2025
When testing LLDP and STP, we observed that locally generated multicast packets (e.g. LLDP, STP) were not restricted to the designated output port(s). For example, when transmitting on `lan1`, the same packet was also forwarded to other ports such as `lan2`. Steps to reproduce: 1. Configure lldpd to use `lan1` in UCI and restart the service 2. Connect devices to `lan1` and `lan2` 3. Observe that the device on `lan2` still receives LLDP packets The issue was caused by an incorrect `FWD_TYPE` setting in the TX CPU TAG, which failed to enforce the selected egress port(s). Fix this by updating the TX CPU TAG to set `FWD_TYPE` correctly, ensuring that locally generated packets are transmitted only on the intended port(s). Signed-off-by: Issam Hamdi <ih@simonwunderlich.de> Link: openwrt#19802 Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Lienol
pushed a commit
to Lienol/openwrt
that referenced
this pull request
Aug 27, 2025
When testing LLDP and STP, we observed that locally generated multicast packets (e.g. LLDP, STP) were not restricted to the designated output port(s). For example, when transmitting on `lan1`, the same packet was also forwarded to other ports such as `lan2`. Steps to reproduce: 1. Configure lldpd to use `lan1` in UCI and restart the service 2. Connect devices to `lan1` and `lan2` 3. Observe that the device on `lan2` still receives LLDP packets The issue was caused by an incorrect `FWD_TYPE` setting in the TX CPU TAG, which failed to enforce the selected egress port(s). Fix this by updating the TX CPU TAG to set `FWD_TYPE` correctly, ensuring that locally generated packets are transmitted only on the intended port(s). Signed-off-by: Issam Hamdi <ih@simonwunderlich.de> Link: openwrt/openwrt#19802 Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When testing LLDP and STP, we observed that locally generated multicast packets (e.g. LLDP, STP) were not restricted to the designated output port(s). For example, when transmitting on
lan1, the same packet was also forwarded to other ports such aslan2.Steps to reproduce:
lan1in UCI and restart the servicelan1andlan2lan2still receives LLDP packetsThe issue was caused by an incorrect
FWD_TYPEsetting in the TX CPU TAG, which failed to enforce the selected egress port(s).Fix this by updating the TX CPU TAG to set
FWD_TYPEcorrectly, ensuring that locally generated packets are transmitted only on the intended port(s).