Trunk link with LuCI on WRT3200ACM

Hi all,
I'm reading all the documentation I could find about OpenWRT network, tagging, VLAN, DSA and similar topics but I can't find a clear, specific and easy to understand solution to my doubt.

How can I setup one single port of the switch (let's say number 4) to get VLAN tags from a manged switch (or from a dumb AP with OpenWRT, it should be the same)?
It does not seem an advanced scenario so I think it should be easily obtained using LuCI.

1 Like

port 4 is tagged on vlan1 and untagged PVID on vlan 2. You can obviously add more tags from other vlans there.

Thank you, I also bookmarked the original post from rmilecki.

It's still not clear to me:

  1. What does it mean to have port 4 tagged on vlan1? What if it will receive a packet for tag 123?
  2. Will I have to add a record in that form for each vlan tag I should add from the switch, or the router will pass them automatically?
  3. Why is it in the same VLAN with the other ports?
  4. Untagged in vlan2 means that if I attached a "stupid" pc to port4 it will work as if it was a normal unmanaged switch? Otherwise the pc wouldn't be able to connect, am I right?

Sorry for the stream of dumb questions; I really appreciate your effort!

  1. It means that frames going out of port 4 are tagged with vlanid 4 and ingress frames should match vlanid 4. It is not configured for 123 so it will be dropped.
  2. You need to add the vlans to pass.
  3. Why not? You might want some ports untagged and others tagged in a certain vlan. Or you might want them to not participate at all.
  4. It means that it will send untagged frames out of this port and that the ingress frames will be classified for vlan 2.

Really thank you, I start to see some light!

Let's say I want to segregate classes of device in their own network.
I have a managed switch (or an AP with multi SSID and thus multi vlan tags).
I have just one cable from switch/AP to the router, on port 4.

If I created 3 different vlan tags, I'd have to add a record for each vlan, I got it.
But can I add port 4 as tagged in each vlan?
In this case, what about the other ports? Untagged or not-partecipant for each vlan record?

Yes, of course.

It depends. You cannot have multiple untagged vlans, so you usually assign the port to an untagged vlan and not participate for the other vlans.

Things are getting really clearer, thank you, thank you thank you!
Just a recap to see if I've understood all the implications:

  • Packet tagged vlan n -> port untagged
    drop

  • Packet untagged -> port untagged
    Sent to tagged and untagged port with same VLAN ID of receiver port

  • Packet tagged vlan n -> port tagged vlan n
    Sent to tagged and untagged port with same VLAN ID of receiver port

  • Packet tagged vlan n -> port tagged vlan x
    drop

So VLAN ID also of untagged port may have some sort of importance.
It's kind of fallback: all untagged packets fall into this ID.
In the doc example: port 4 is tagged for vlan 1 but it can also receive untagged packet and they will be considered as vlan 2.

Last question, I hope:
what if untagged packet is received on tagged (and only tagged) port? Drop?

Yes, if there is no pvid.

1 Like

Here I am, with new and exciting doubts...
Using my new knowledge, I've been trying to design a network with 4 VLANs.
I've set up a dumb AP with 4 different SSIDs, one for each VLAN.
Just one single cable connects the main router port 1 with one of the AP ports.

Router side I'd configure something like this:

In my idea, this way port 1 is the trunk link and it's able to manage packages tagged for all the existing VLANs, while the other ports keep working as always, having all connected devices on the VLAN 1 (my main LAN).

I'd also set Primary VLAN ID on port 1 :
image

Does this mean port 1 can also receive untagged packets and consider them as VLAN 1?
Also, I kept Local checkbox checked, but what does it mean?
Have I done this right?

Yes, but it is a bad practice. If you don't expect untagged frames, better drop them. Frames from vlan 1 should come tagged, as they are going to egress.

I think it means that the vlan can be used locally, that means to have a vlan subinterface.

Other than the pvid on port 1, it looks fine.

Again, thank you.
I have to bother with another question: what if I flag pvid on untagged ports? What does it mean?
When edited the bridge config: should I also edit the LAN interface to point on a different device (such as br-lan.1) to not be closed outside?

And what will happen to dhcp and dns packets from AP while I will be still editing only the router side?

It means that ingress untagged frames are assigned to that specific vlan.

As per documentation, yes you must use the br-lan.1 . However when you make such changes it is highly advised to use a dedicated interface assigned only to a wifi which won't be affected by the changes in ports and vlans.

If the settings don't match on both sides, they most likely will be dropped.

Isn't this the default?
If I have port 2 untagged only on one single VLAN, don't the packages go to VLAN 2 by default?

No, they don't. They go to vlan 1. And this is not some particular issue of OpenWrt, I've seen it in tp-link switches too.

Really thanks a lot for your patience!

I think I've really understood the rules, but I'm facing a weird behavior...
With my new knowledge, I've set up Router and AP:

ROUTER

DUMB AP

The cable runs from Router.lan1 to AP.wan and I'm connected to the AP wifi, so should be in VLAN 1.
All it's working as expected.

But if I connect the AP.wan port to Router.lan3 I'm still able to browse Internet.
I'm writing this post with this connection in place...

I though that AP.wan, having only tagged vlan, shouldn't be able to send packets to router untagged ports.

What am I missing?

Sounds strange, can you take a packet capture from lan3 port?
opkg update; opkg install tcpdump; tcpdump -i lan3 -evn -c 10

Was lan4, my bad.
MAC partially obfuscated

root@Router:~# tcpdump -i lan4 -evn -c 10
tcpdump: listening on lan4, link-type EN10MB (Ethernet), capture size 262144 bytes
16:00:52.741889 e8:9f:80:1c:xx:xx > 70:1c:e7:59:xx:xx, ethertype IPv4 (0x0800), length 118: (tos 0x10, ttl 64, id 62461, offset 0, flags [DF], proto TCP (6), length 104)
    192.168.0.1.22 > 192.168.0.67.16251: Flags [P.], cksum 0x81ef (incorrect -> 0x071d), seq 3554015049:3554015113, ack 1405470178, win 1002, length 64
16:00:52.742005 e8:9f:80:1c:xx:xx > 70:1c:e7:59:xx:xx, ethertype IPv4 (0x0800), length 182: (tos 0x10, ttl 64, id 62462, offset 0, flags [DF], proto TCP (6), length 168)
    192.168.0.1.22 > 192.168.0.67.16251: Flags [P.], cksum 0x822f (incorrect -> 0xf0d0), seq 64:192, ack 1, win 1002, length 128
16:00:52.742180 e8:9f:80:1c:xx:xx > 70:1c:e7:59:xx:xx, ethertype IPv4 (0x0800), length 278: (tos 0x10, ttl 64, id 62463, offset 0, flags [DF], proto TCP (6), length 264)
    192.168.0.1.22 > 192.168.0.67.16251: Flags [P.], cksum 0x828f (incorrect -> 0x373a), seq 192:416, ack 1, win 1002, length 224
16:00:52.742313 e8:9f:80:1c:xx:xx > 70:1c:e7:59:xx:xx, ethertype IPv4 (0x0800), length 262: (tos 0x10, ttl 64, id 62464, offset 0, flags [DF], proto TCP (6), length 248)
    192.168.0.1.22 > 192.168.0.67.16251: Flags [P.], cksum 0x827f (incorrect -> 0x612f), seq 416:624, ack 1, win 1002, length 208
16:00:52.742424 e8:9f:80:1c:xx:xx > 70:1c:e7:59:xx:xx, ethertype IPv4 (0x0800), length 278: (tos 0x10, ttl 64, id 62465, offset 0, flags [DF], proto TCP (6), length 264)
    192.168.0.1.22 > 192.168.0.67.16251: Flags [P.], cksum 0x828f (incorrect -> 0x62ed), seq 624:848, ack 1, win 1002, length 224
16:00:52.742524 e8:9f:80:1c:xx:xx > 70:1c:e7:59:xx:xx, ethertype IPv4 (0x0800), length 246: (tos 0x10, ttl 64, id 62466, offset 0, flags [DF], proto TCP (6), length 232)
    192.168.0.1.22 > 192.168.0.67.16251: Flags [P.], cksum 0x826f (incorrect -> 0x0250), seq 848:1040, ack 1, win 1002, length 192
16:00:52.742647 e8:9f:80:1c:xx:xx > 70:1c:e7:59:xx:xx, ethertype IPv4 (0x0800), length 278: (tos 0x10, ttl 64, id 62467, offset 0, flags [DF], proto TCP (6), length 264)
    192.168.0.1.22 > 192.168.0.67.16251: Flags [P.], cksum 0x828f (incorrect -> 0x44ca), seq 1040:1264, ack 1, win 1002, length 224
16:00:52.742746 e8:9f:80:1c:xx:xx > 70:1c:e7:59:xx:xx, ethertype IPv4 (0x0800), length 246: (tos 0x10, ttl 64, id 62468, offset 0, flags [DF], proto TCP (6), length 232)
    192.168.0.1.22 > 192.168.0.67.16251: Flags [P.], cksum 0x826f (incorrect -> 0x9974), seq 1264:1456, ack 1, win 1002, length 192
16:00:52.742854 e8:9f:80:1c:xx:xx > 70:1c:e7:59:xx:xx, ethertype IPv4 (0x0800), length 278: (tos 0x10, ttl 64, id 62469, offset 0, flags [DF], proto TCP (6), length 264)
    192.168.0.1.22 > 192.168.0.67.16251: Flags [P.], cksum 0x828f (incorrect -> 0xfe3d), seq 1456:1680, ack 1, win 1002, length 224
16:00:52.742952 e8:9f:80:1c:xx:xx > 70:1c:e7:59:xx:xx, ethertype IPv4 (0x0800), length 246: (tos 0x10, ttl 64, id 62470, offset 0, flags [DF], proto TCP (6), length 232)
    192.168.0.1.22 > 192.168.0.67.16251: Flags [P.], cksum 0x826f (incorrect -> 0xaa09), seq 1680:1872, ack 1, win 1002, length 192
10 packets captured
16 packets received by filter
0 packets dropped by kernel

Try it like this, it got overrun by ssh packets.
tcpdump -i lan3 -evn -c 10 not port 22

root@Router:~# tcpdump -i lan4 -evn -c 10 not port 22
tcpdump: listening on lan4, link-type EN10MB (Ethernet), capture size 262144 bytes
16:18:41.821322 e8:9f:80:1c:xx:xx > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.149 tell 192.168.0.1, length 28
16:18:41.836351 e8:9f:80:1c:xx:xx > 68:3a:48:1b:xx:xx, ethertype IPv4 (0x0800), length 85: (tos 0x0, ttl 221, id 60767, offset 0, flags [DF], proto TCP (6), length 71)
    52.213.45.205.443 > 192.168.0.141.7485: Flags [FP.], cksum 0xdb6b (correct), seq 3425276583:3425276614, ack 37708581, win 65535, length 31
16:18:41.867093 e8:9f:80:1c:xx:xx > 70:1c:e7:59:xx:xx, ethertype IPv4 (0x0800), length 54: (tos 0x0, ttl 107, id 57156, offset 0, flags [DF], proto TCP (6), length 40)
    52.112.120.18.443 > 192.168.0.67.16271: Flags [.], cksum 0x477b (correct), ack 3516455069, win 2049, length 0
16:18:41.927630 70:1c:e7:59:xx:xx > e8:9f:80:1c:xx:xx, ethertype 802.1Q (0x8100), length 1270: vlan 1, p 0, ethertype IPv4, (tos 0x0, ttl 128, id 427, offset 0, flags [none], proto UDP (17), length 1252)
    192.168.0.67.53438 > 52.114.74.118.3478: UDP, length 1224
16:18:41.969433 e8:9f:80:1c:xx:xx > 70:1c:e7:59:xx:xx, ethertype IPv4 (0x0800), length 49: (tos 0x0, ttl 110, id 59339, offset 0, flags [none], proto UDP (17), length 35)
    52.114.74.118.3478 > 192.168.0.67.53438: UDP, length 7
16:18:41.969445 e8:9f:80:1c:xx:xx > 70:1c:e7:59:xx:xx, ethertype IPv4 (0x0800), length 79: (tos 0x0, ttl 110, id 59340, offset 0, flags [none], proto UDP (17), length 65)
    52.114.74.118.3478 > 192.168.0.67.53438: UDP, length 37
16:18:41.981305 e8:9f:80:1c:xx:xx > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.10 tell 192.168.0.1, length 28
16:18:42.072486 70:1c:e7:59:xx:xx > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 96: vlan 1, p 0, ethertype IPv4, (tos 0x0, ttl 128, id 17471, offset 0, flags [none], proto UDP (17), length 78)
    192.168.0.67.137 > 192.168.0.255.137: UDP, length 50
16:18:42.073849 e8:9f:80:1c:xx:xx > 70:1c:e7:59:xx:xx, ethertype IPv4 (0x0800), length 79: (tos 0x0, ttl 110, id 59341, offset 0, flags [none], proto UDP (17), length 65)
    52.114.74.118.3478 > 192.168.0.67.53438: UDP, length 37
16:18:42.073859 e8:9f:80:1c:xx:xx > 70:1c:e7:59:xx:xx, ethertype IPv4 (0x0800), length 49: (tos 0x0, ttl 110, id 59342, offset 0, flags [none], proto UDP (17), length 35)
    52.114.74.118.3478 > 192.168.0.67.53438: UDP, length 7
10 packets captured
10 packets received by filter
0 packets dropped by kernel

...and I'm connected to APwifi -> AP.wan -> Router.lan4

Could be this the devil's detail?

Could this setting force the port to accept tagged packets if they have the the VLAN 1 tag?