No communication between OpenWrt and LAN/WAN (WLAN works fine) | ZTE 283+

Hello everyone,

My first time to use OpenWrt, but I think my problem sits somewhere beyond being new here.

TL;DR: A PC connected to any LAN/WAN port of the MF283+ is not able to open GUI/LuCi or SSH or PING connection to 192.168.1.1. The same PC connecting over Wi-Fi connects just fine. First issue is, that no DHCP lease is issued, but even with a static IP address no connection is possible. The other way around is the same issue (the PC would answer a PING request, but never receives one).

I am running OpenWrt 22.03.0 r19685-512e76967f on a ZTE 283+ 3G/4G WLAN Router.

(Source)

I've used the Upgrade version from this site as described here by Lech Perczak.

After the first/initial installation I've tried to connect to LuCi on 192.168.1.1. Since no DHCP lease was issued, I've set up a static address in my PC and tried again without success.
A couple Google searches later I found a Filipino thread, that explained, that the network cable should be unplugged when the router is turned on and then it needs to be plugged in immediately once the boot finished.

Following that advice, I could successfully log in and set up my WLAN network. But soon I had to find out, that the communication over CABLE was impossible. Trying to find a fix, made me lose my wireless connection and I had to start over. You will find two sets of LAN and WLAN in my configuration. The second one is just the backdoor entry. Learned the hard way.

Let’s start with the configuration and then I'll describe my trails and errors.

(Please click for details.)

/etc/config/network
root@OpenWrt:/# cat /etc/config/network

config interface 'loopback'
        option device 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'
        option ula_prefix 'fd21:ad7a:8d11::/48'

config switch
        option name 'switch0'
        option reset '1'
        option enable_vlan '1'

config switch_vlan
        option device 'switch0'
        option vlan '1'
        option ports '6t 0 1 2'

config switch_vlan
        option device 'switch0'
        option vlan '2'
        option ports '6t 3'

config device
        option name 'br-lan'
        option type 'bridge'
        list ports 'eth0.1'

config interface 'lan'
        option proto 'static'
        option device 'br-lan'
        option ipaddr '192.168.1.1'
        option netmask '255.255.255.0'
        option gateway '192.168.1.250'
        list dns '8.8.8.8'
        list dns '8.8.4.4'

config device
        option name 'br-s_lan'
        option type 'bridge'
        list ports 'eth0.2'

config interface 's_lan'
        option proto 'static'
        option device 'br-s_lan'
        option ipaddr '192.168.2.1'
        option netmask '255.255.255.0'

/etc/config/wireless
root@OpenWrt:~# cat /etc/config/wireless

config wifi-device 'radio0'
        option type 'mac80211'
        option path 'platform/10180000.wmac'
        option channel '1'
        option band '2g'
        option htmode 'HT20'
        option cell_density '0'
	option country 'TW'

config wifi-iface 'default_radio0'
        option device 'radio0'
        option network 'lan'
        option mode 'ap'
        option ssid 'OpenWrt'
        option encryption 'psk2'
        option key '**secure_pass**'

config wifi-iface 'wifinet1'
        option device 'radio0'
        option network 's_lan'
        option mode 'ap'
        option ssid 'OpenWrt (System)'
        option encryption 'psk2'
        option key '**secure_pass**'
/etc/config/firewall
root@OpenWrt:~# cat /etc/config/firewall

config defaults
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'REJECT'
        option synflood_protect '1'

config zone
        option name 'lan'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'ACCEPT'
        list network 'lan'

config zone
        option name 's_lan'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'ACCEPT'
        list network 's_lan'

config zone
        option name 'wan'
        option output 'ACCEPT'
        option forward 'REJECT'
        option input 'REJECT'
        option mtu_fix '1'
        option masq '1'
        list network 'wan6'

config forwarding
        option src 'lan'
        option dest 's_lan'

config forwarding
        option src 'lan'
        option dest 'wan'

config forwarding
        option src 's_lan'
        option dest 'lan'

config forwarding
        option src 's_lan'
        option dest 'wan'

config rule
        option name 'Allow-DHCP-Renew'
        option src 'wan'
        option proto 'udp'
        option dest_port '68'
        option family 'ipv4'
        option target 'ACCEPT'

config rule
        option name 'Allow-Ping'
        option src 'wan'
        option proto 'icmp'
        option icmp_type 'echo-request'
        option family 'ipv4'
        option target 'ACCEPT'

config rule
        option name 'Allow-IGMP'
        option src 'wan'
        option proto 'igmp'
        option family 'ipv4'
        option target 'ACCEPT'

config rule
        option name 'Allow-DHCPv6'
        option src 'wan'
        option proto 'udp'
        option dest_port '546'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-MLD'
        option src 'wan'
        option proto 'icmp'
        option src_ip 'fe80::/10'
        list icmp_type '130/0'
        list icmp_type '131/0'
        list icmp_type '132/0'
        list icmp_type '143/0'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-ICMPv6-Input'
        option src 'wan'
        option proto 'icmp'
        list icmp_type 'echo-request'
        list icmp_type 'echo-reply'
        list icmp_type 'destination-unreachable'
        list icmp_type 'packet-too-big'
        list icmp_type 'time-exceeded'
        list icmp_type 'bad-header'
        list icmp_type 'unknown-header-type'
        list icmp_type 'router-solicitation'
        list icmp_type 'neighbour-solicitation'
        list icmp_type 'router-advertisement'
        list icmp_type 'neighbour-advertisement'
        option limit '1000/sec'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-ICMPv6-Forward'
        option src 'wan'
        option dest '*'
        option proto 'icmp'
        list icmp_type 'echo-request'
        list icmp_type 'echo-reply'
        list icmp_type 'destination-unreachable'
        list icmp_type 'packet-too-big'
        list icmp_type 'time-exceeded'
        list icmp_type 'bad-header'
        list icmp_type 'unknown-header-type'
        option limit '1000/sec'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-IPSec-ESP'
        option src 'wan'
        option dest 'lan'
        option proto 'esp'
        option target 'ACCEPT'

config rule
        option name 'Allow-ISAKMP'
        option src 'wan'
        option dest 'lan'
        option dest_port '500'
        option proto 'udp'
        option target 'ACCEPT'

As you can see, it is a very standard configuration. I would like to point out, that Ports 1-3 are assigned to VLAN1 and only Port 4 is assigned to VLAN2. This is for test purposes, as described later. Also, the MF283+ doesn’t differentiate between LAN and WAN ports. The stock software uses Port 1 as LAN or WAN depending on the use MODE selected.


Here a little test setup:

PC1 is connected through an unmanaged switch to Port 1 of the box; PC2 is connected directly to Port 2; and PC3 is connected via WLAN. DHCP fails in both wired cases, so setting both PCs to static IPs (PC1: 192.168.1.11; PC2 192.168.1.12); PC3 got the IP 192.168.1.103 through a DHCP lease.

PING results: (details)

PC1

  • :no_entry_sign: 192.168.1.1 (OpenWrt)
  • :white_check_mark: 192.168.1.12 (PC2)
  • :no_entry_sign: 192.168.1.103 (PC3)

PC2

  • :no_entry_sign: 192.168.1.1 (OpenWrt)
  • :white_check_mark: 192.168.1.11 (PC1)
  • :no_entry_sign: 192.168.1.103 (PC3)

PC3

  • :white_check_mark: 192.168.1.1 (OpenWrt)
  • :no_entry_sign: 192.168.1.11 (PC1)
  • :no_entry_sign: 192.168.1.12 (PC2)

OpenWrt | from device: br-lan

  • :no_entry_sign: 192.168.1.11 (PC1)
  • :no_entry_sign: 192.168.1.12 (PC2)
  • :white_check_mark: 192.168.1.103 (PC3)

OpenWrt | from device: eth0

  • :no_entry_sign: 192.168.1.11 (PC1)
  • :no_entry_sign: 192.168.1.12 (PC2)
  • :no_entry_sign: 192.168.1.103 (PC3)

OpenWrt | from device: eth0.1

  • :white_check_mark: 192.168.1.11 (PC1)
  • :white_check_mark: 192.168.1.12 (PC2)
  • :no_entry_sign: 192.168.1.103 (PC3)

I believe this ping table gives a nice overview of what communication paths are available or not.

[Edit]: And now - for some reason (maybe reboot) - all communication via wired connection stopped. ping only works on WLAN. :sob: [/Edit]

I was - however - wondering, if PC1 could communicate with PC2, if it was connected to Port 4 (VLAN2). I just wanted to check if VLAN actually worked or if the box simply turned into a hub. Like some kind of fallback behavior.

The result is, that VLAN is working fine and OpenWrt keeps them tidely separated.

PC1 <=> PC2 (original IP)

  • :no_entry_sign: 192.168.1.11 (PC1) => 192.168.1.12 (PC2)
  • :no_entry_sign: 192.168.1.12 (PC2) => 192.168.1.11 (PC1)

PC1 <=> PC2 (new/adjusted IP)

  • :no_entry_sign: 192.168.1.11 (PC1) => 192.168.2.12 (PC2)
  • :no_entry_sign: 192.168.2.12 (PC2) => 192.168.1.11 (PC1)

You might wonder if the gateway entry messes things up...

option gateway '192.168.1.250'
list dns '8.8.8.8'
list dns '8.8.4.4'

...but nope! Even without, still the same result. I’ve tried too often.

Changing the proto doesn't help either, because...

option proto 'static'
option proto 'dhcp'

...even when I run a DHPC server on PC1 or PC2, it will never be able to see a request or offer/send a lease. And yes, I've tried.


Please help! I've searched and tried and nothing seems to fix the issue. I believe my configuration is fine.

If anyone can see my mistake or knows what the problem is or how to fix it, please be so kind to guide me. Even the slightest idea of a potential solution is welcome. I really run out of options/ideas at the moment.

Thank you and kind regards.

I think underscores ("_") can cause problems in the UCI syntax. Try changing that to a regular dash "-" (here and everywhere else that you used an underscore) and then reboot.

You do not have any wan interfaces defined at all... is this device connected to the internet? If so, how?

I changed all s_lan into system. No more underscores in the configuration (besides where appropriate).

option name 'br-s_lan'
option name 'br-system'

/etc/config/network
root@OpenWrt:/# cat /etc/config/network

config interface 'loopback'
        option device 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'
        option ula_prefix 'fd21:ad7a:8d11::/48'

config switch
        option name 'switch0'
        option reset '1'
        option enable_vlan '1'

config switch_vlan
        option device 'switch0'
        option vlan '1'
        option ports '6t 0 1 2'

config switch_vlan
        option device 'switch0'
        option vlan '2'
        option ports '6t 3'

config device
        option name 'br-lan'
        option type 'bridge'
        list ports 'eth0.1'

config interface 'lan'
        option proto 'static'
        option device 'br-lan'
        option ipaddr '192.168.1.1'
        option netmask '255.255.255.0'
        option gateway '192.168.1.250'
        list dns '8.8.8.8'
        list dns '8.8.4.4'

config device
        option name 'br-system'
        option type 'bridge'
        list ports 'eth0.2'

config interface 'system'
        option proto 'static'
        option device 'br-system'
        option ipaddr '192.168.2.1'
        option netmask '255.255.255.0'

/etc/config/wireless
root@OpenWrt:~# cat /etc/config/wireless

config wifi-device 'radio0'
        option type 'mac80211'
        option path 'platform/10180000.wmac'
        option channel '1'
        option band '2g'
        option htmode 'HT20'
        option cell_density '0'
	option country 'TW'

config wifi-iface 'default_radio0'
        option device 'radio0'
        option network 'lan'
        option mode 'ap'
        option ssid 'OpenWrt'
        option encryption 'psk2'
        option key '**secure_pass**'

config wifi-iface 'wifinet1'
        option device 'radio0'
        option network 'system'
        option mode 'ap'
        option ssid 'OpenWrt (System)'
        option encryption 'psk2'
        option key '**secure_pass**'
/etc/config/firewall
root@OpenWrt:~# cat /etc/config/firewall

config defaults
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'REJECT'
        option synflood_protect '1'

config zone
        option name 'lan'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'ACCEPT'
        list network 'lan'

config zone
        option name 'system'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'ACCEPT'
        list network 'system'

config zone
        option name 'wan'
        option output 'ACCEPT'
        option forward 'REJECT'
        option input 'REJECT'
        option mtu_fix '1'
        option masq '1'
        list network 'wan6'

config forwarding
        option src 'lan'
        option dest 'system'

config forwarding
        option src 'lan'
        option dest 'wan'

config forwarding
        option src 'system'
        option dest 'lan'

config forwarding
        option src 'system'
        option dest 'wan'

config rule
        option name 'Allow-DHCP-Renew'
        option src 'wan'
        option proto 'udp'
        option dest_port '68'
        option family 'ipv4'
        option target 'ACCEPT'

config rule
        option name 'Allow-Ping'
        option src 'wan'
        option proto 'icmp'
        option icmp_type 'echo-request'
        option family 'ipv4'
        option target 'ACCEPT'

config rule
        option name 'Allow-IGMP'
        option src 'wan'
        option proto 'igmp'
        option family 'ipv4'
        option target 'ACCEPT'

config rule
        option name 'Allow-DHCPv6'
        option src 'wan'
        option proto 'udp'
        option dest_port '546'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-MLD'
        option src 'wan'
        option proto 'icmp'
        option src_ip 'fe80::/10'
        list icmp_type '130/0'
        list icmp_type '131/0'
        list icmp_type '132/0'
        list icmp_type '143/0'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-ICMPv6-Input'
        option src 'wan'
        option proto 'icmp'
        list icmp_type 'echo-request'
        list icmp_type 'echo-reply'
        list icmp_type 'destination-unreachable'
        list icmp_type 'packet-too-big'
        list icmp_type 'time-exceeded'
        list icmp_type 'bad-header'
        list icmp_type 'unknown-header-type'
        list icmp_type 'router-solicitation'
        list icmp_type 'neighbour-solicitation'
        list icmp_type 'router-advertisement'
        list icmp_type 'neighbour-advertisement'
        option limit '1000/sec'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-ICMPv6-Forward'
        option src 'wan'
        option dest '*'
        option proto 'icmp'
        list icmp_type 'echo-request'
        list icmp_type 'echo-reply'
        list icmp_type 'destination-unreachable'
        list icmp_type 'packet-too-big'
        list icmp_type 'time-exceeded'
        list icmp_type 'bad-header'
        list icmp_type 'unknown-header-type'
        option limit '1000/sec'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-IPSec-ESP'
        option src 'wan'
        option dest 'lan'
        option proto 'esp'
        option target 'ACCEPT'

config rule
        option name 'Allow-ISAKMP'
        option src 'wan'
        option dest 'lan'
        option dest_port '500'
        option proto 'udp'
        option target 'ACCEPT'

Unfortunately the issue is not resolved by these steps. But I do thank you for the hint, as it might safe some troubles down the line at a later point.

No, at the moment neither a wan interface is setup, nor is this box connected to the internet. Currently it is just a simple lab setup to figure out/isolate this issue.

Thanks again.

PS: Because I wanted to try your idea real fast, so I manually edited the config files. However, I forgotten the firewall config and locked myself out (front and back door). “Fast” cost me one hour, but I’m getting good at flashing this box. :rofl:

You should probably remove the gateway and DNS entries in your lan network definition, but that is not the cause of your issues.

Can you post your /etc/config/dhcp file?

BTW, this is not what's happening. Something else is wrong. VLANs/firewall do not operate on the same subnet (192.168.1.11 and 192.168.1.12 are both on the 192.168.1.0/24 network), so you should be able to connect between them without issue. Besides, you said that they were connected to an unmanaged switch... in that case, the router isn't doing anything at all since they can theoretically connect to each other at L2 (switching).

You said that you assigned static IPs to these PCs -- what is the complete information you entered into the network config?

Also, do these PCs have any other network connections? Wifi should be disabled and the only active connection should be the one directly to this test network.

As mentioned in the original post, I am aware…

Original post

…but I will leave this information in the configuration, because I might forget to enter it at a later stage. It is totally irrelevant at the moment.

I am not quite sure why you’re interested in the DHCP, as it is running just fine. The wired and wireless networks are bridged. If DHCP is working on the wireless side, it will work on the wired side as well. Just that the wired side has an issue in all communication.
But for completeness, here you go:

/etc/config/dhcp
root@OpenWrt:~# cat /etc/config/dhcp

config dnsmasq
        option domainneeded '1'
        option boguspriv '1'
        option filterwin2k '0'
        option localise_queries '1'
        option rebind_protection '1'
        option rebind_localhost '1'
        option local '/lan/'
        option domain 'lan'
        option expandhosts '1'
        option nonegcache '0'
        option authoritative '1'
        option readethers '1'
        option leasefile '/tmp/dhcp.leases'
        option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto'
        option nonwildcard '1'
        option localservice '1'
        option ednspacket_max '1232'

config dhcp 'lan'
        option interface 'lan'
        option start '100'
        option limit '150'
        option leasetime '12h'
        option dhcpv4 'server'
        option dhcpv6 'server'
        option ra 'server'
        list ra_flags 'managed-config'
        list ra_flags 'other-config'

config dhcp 'system'
        option interface 'system'
        option start '100'
        option limit '150'
        option leasetime '12h'

config dhcp 'wan'
        option interface 'wan'
        option ignore '1'

config odhcpd 'odhcpd'
        option maindhcp '0'
        option leasefile '/tmp/hosts/odhcpd'
        option leasetrigger '/usr/sbin/odhcpd-update'
        option loglevel '4'

Just the standard DHCP configuration.

That is not or only partially correct. It has nothing to do with the firewall, but 192.168.1.11 of VLAN1 is not in the same network as 192.168.1.12 of VLAN2. Two logically separated networks with the same address range. And theoretically OpenWrt could route between those two networks, but that’s beyond this thread.

I’ve never said that. I’ve mentioned, that PC1 is connected to OpenWrt through an unmanaged switch. I’ve decided to have one PC connected directly and one through a switch, because sometimes a switch makes a difference and – if so – I would like to observe it.

PC1 & PC2:

IP-Address: 192.168.1.xx
Subnet: 255.255.255.0

PC3:

is set as DHCP client

But I did try to set OpenWrt as gateway for testing before.

Thanks for asking, but rest assured. Those PCs only use the designated network connection. But since PC3 is supposed to connect through WLAN, its Wi-Fi connection is enabled.

I’d like to remind, that the communication between the PCs is not the issue. It is absolutely secondary and simply a tool for diagnosis. The lab is setup to test communication between PC and OpenWrt, because the trouble part lies somewhere between the CPU and the physical ethernet port of the MH283+.

Without logs you are flailing in the dark.

Install tcpdump on the device and watch what packets the router sees while you do your pings.

Do the same with wireshark on the pcs.

This will likely give you something to go on.

Your tone appears to have become more agitated and confrontational... at least that is how it reads to me. I'll ignore it and assume it's just my interpretation.

I know... but I am suggesting this because it eliminates variables that could impact things negatively. You don't have an upstream connection, so DNS and a gateway are irrelevant. They shouldn't cause problems, but given that they aren't relevant currently, I recommend taking them out.

Standard troubleshooting. There are 4 files that are commonly useful, this was the only one that was omitted originally. Thank you for providing it -- it is indeed pretty standard, but I wanted to make sure.

I'm really confused about your take here. Both of those addresses are absolutely part of the same /24 subnet -- and they are both part of VLAN1.
As I read your configuration:

  • VLAN 1 -> 192.168.1.0/24 (192.168.1.1-192.168.1.254)
  • VLAN 2 -> 192.168.2.0/24 (192.168.2.1-192.168.2.254)

This is certainly not possible. Two logically separated networks must have different address ranges. Otherwise, there is no way to route between them. And anything that exists on the same subnet is switched (L2), not routed (L3). Anything that is switched will not traverse the routing engine and firewall.

So, if you have 2 PCs connected to an unmanaged switch (any switch) with addresses in the same subnet, they will necessarily be able to communicate without needing any router at all (assuming their local firewalls don't block it).

I was only talking about PCs 1 and 2, but must have misinterpreted...

I though that PC2 was connected to port 2 of the unmanaged switch... but I stand corrected.

What difference are you expecting to see here? In theory, there should be no difference unless there are problems with link negotiation or port flapping, but that's rare. If anything, adding additional bits of hardware can cause additional issues because you could have a faulty switch/switch port, or a faulty cable in the mix.

While we are here, though... I'll recommend the following:

  • connect both PCs to the unmanaged switch directly and make no other connections.

  • give each PC a static IP in the 192.168.1.0/24 range (the IPs and subnets you've already been using are fine)

  • run a ping test between those two PCs.
    ---> if it succeeds, your PCs and the switch and those cables are working properly. If this fails, you have a problem with one of those items.

  • Then, connect both PCs to your router's built-in switch (make sure you use the ports associated with VLAN1 for this). Use the same cables as in the previous test.

  • repeat the ping test.
    ---> if the switch on the router is working properly, the result should be successful.

  • ping the router's address (192.168.1.1)
    ----> if the test is successful, that means the router's lan interface is properly configured.

Now, if all of that is working, you can change the PCs to get a DHCP address (instead of static) and it should work. If it doesn't, we'll take a closer look, but this would surprise me

Finally, you can introduce your external switch into the equation... you'll be adding an additional cable to the mix, of course, so that will also need to be verified to be functioning properly.

But it is failing -- this means that something more fundamental is wrong.

That may be another issue, but if your PCs cannot communicate, you need to stop and fix the first issue.

You’re absolutely correct, I am failing in the dark big times. But without internet connection, I have no way to install any tools. So, I am focused to get the box online through a/the Wi-Fi client. More on that later. [Spoiler: I managed to get the box online]

I am observing the traffic on the LAN already. But there simply isn’t any traffic coming from the router.

Not knowing where you are from, but it might simply be a cultural difference. As a German, we tend to be known for being very direct and straightforward, which can feel confrontational to others, but to Germans it is just a more clear and efficient way of communication. And I’ve had a few extra spoons of that trait when growing up.

Yeah, I think we should take a moment to discuss VLANs. But as it isn’t really part of this thread, I will hide it behind the link below. Maybe we continue the VLAN discussion in a separate thread or privately.

VLAN discussion

In principle, your interpretation is correct, but only partially. However, I’ve nowhere configured those address ranges as belonging to a particular VLAN. Yes, in my head that is how it is intended, but it is not configured anywhere. And it cannot even be configured, because I can use addresses from multiple address ranges on any network.

That’s also why PC2 with IP address 192.168.1.12 connected to Port 4 of the router is part of VLAN2 and cannot communicate with PC1 (192.168.1.11) on VLAN1. Just to be clear, in reality PC2 is connected to Port 2 and is part of VLAN1.

VLAN ≠ vLAN

Your interpretation sounds very much, like you’re talking about vLAN. But vLAN is something else, even it definitely overlaps. A single or multiple VLANs can run entirely on a vLAN.

Short summary of vLAN: vLAN describes software emulated (virtualized) network equipment. For example, virtual NICs, cables/connections and even virtual switches. They can be used to deploy entire virtualized networks or can be used as extension to a physical network.

VLAN is a bit trickier to describe. Allow me to setup a little scenario.

Person A has an independent network. Few clients, one switchÂą, and no outside connection. IP addresses are assigned from the 192.168.0.0/24 range.

Person B has an exact copy of that network.

| Âą The switch is unmanaged, but capable of passing VLAN tags through

Now VLAN is, when the network of Person A and the network of Person B are sitting on top of each other, using the same physical network, only separated by VLAN ID tags.

Since the two VLANs are using the same address range, adding a router and actually routing between these networks becomes very annoying, because of the NAT setup (more like a double NAT). Masquerading would simplify it, but it would be possible to translate the entire address range in both directions.

Or imagine the following scenario. Two Webservers; SRV1 with IP address 192.168.0.1 and SRV2 with the IP address 192.168.0.1. The difference is that SRV1s NIC is set to VLAN ID 1 and SRV2 is set to VLAN ID 2. Both are connected to the same switchÂą and so is PC with IP address 192.168.0.2. If the NIC of PC is set to VLAN ID 1 a browser on PC will display the website hosted by SRV1. Changing the VLAN ID of PC to 2, and a refresh will load the website hosted by SRV2. Changing the VLAN ID is essentially like unplugging from one physical network and plugging into another one.

And of course, we want to use different address ranges for different VLANs, because routing would be a nightmare. But we don’t have to, and routing is possible and kind of straightforward.

This doesn't really belong to VLAN, but routing between networks of the same address range happens all the time on the internet. It requires two sets of address translation (NAT), but that’s about it. And the same is true for all IP networks, no matter how small.

Maybe I am old school, but when communication between two directly connected devices fails (and it is not a firewall issue), I want to grab a crossover cable. Sure, the router should support auto MDI-X, but what if the “auto” part failed? I don’t really know, what I am expecting to see, but since I want to establish communication between one PC and the router (and not the two PCs), this isn’t adding points of failure, but removing some.

[UPDATE 1]:

I've managed to work out the behavior of the switch portion of the router. It seems, that occasionally a change to the configuration isn't written properly and will result in no switching or forwarding between ports. An additional change/update will correct the error and the switch part will work after a reboot. This part is no longer an issue and behavior is as expected and described in the original post before the Edit.
[Edit:] I just noticed, that the original post showed, that a ping from eth0.1 to PC1 & PC2 worked. I cannot recall if that is true, or was just wishful thinking. I will flash the box at a later moment to check if I can recreate that behavior. [/Edit]

Here are the results

A few additional ping results from PC3 and the router

Some more results

[UPDATE 2]:

I’ve managed to setup PC3 as an internet gateway for the router. The router is able to access the internet through the Wi-Fi client. Therefore, the gateway address is currently still part of the configuration.

And since I do have internet access on the router now, I managed to install tcpdump.

tcpdump
root@OpenWrt:~# tcpdump ip
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
04:12:09.386032 IP 192.168.1.12.57192 > 239.255.255.250.1900: UDP, length 146
04:12:09.388009 IP 192.168.1.12.57193 > 239.255.255.250.1900: UDP, length 146
04:12:09.493944 IP 192.168.1.12.57192 > 239.255.255.250.1900: UDP, length 146
04:12:09.494307 IP 192.168.1.12.57193 > 239.255.255.250.1900: UDP, length 146
04:12:09.602497 IP 192.168.1.12.57192 > 239.255.255.250.1900: UDP, length 146
04:12:09.602916 IP 192.168.1.12.57193 > 239.255.255.250.1900: UDP, length 146
04:12:47.067134 IP 192.168.1.12.53764 > 239.255.255.250.1900: UDP, length 175
04:12:48.070698 IP 192.168.1.12.53764 > 239.255.255.250.1900: UDP, length 175
04:12:49.078872 IP 192.168.1.12.53764 > 239.255.255.250.1900: UDP, length 175
04:12:50.087109 IP 192.168.1.12.53764 > 239.255.255.250.1900: UDP, length 175
04:13:01.105614 IP 192.168.1.11.50896 > 239.255.255.250.1900: UDP, length 175
04:13:02.100953 IP 192.168.1.11.50896 > 239.255.255.250.1900: UDP, length 175
04:13:03.093994 IP 192.168.1.11.50896 > 239.255.255.250.1900: UDP, length 175
04:13:04.087118 IP 192.168.1.11.50896 > 239.255.255.250.1900: UDP, length 175
04:13:08.949043 IP 192.168.1.12.57192 > 239.255.255.250.1900: UDP, length 146
04:13:08.949838 IP 192.168.1.12.57193 > 239.255.255.250.1900: UDP, length 146
04:13:09.057457 IP 192.168.1.12.57192 > 239.255.255.250.1900: UDP, length 146
04:13:09.058302 IP 192.168.1.12.57193 > 239.255.255.250.1900: UDP, length 146
04:13:09.166010 IP 192.168.1.12.57192 > 239.255.255.250.1900: UDP, length 146
04:13:09.166806 IP 192.168.1.12.57193 > 239.255.255.250.1900: UDP, length 146
04:14:08.518663 IP 192.168.1.12.57192 > 239.255.255.250.1900: UDP, length 146
04:14:08.519110 IP 192.168.1.12.57193 > 239.255.255.250.1900: UDP, length 146
04:14:08.626546 IP 192.168.1.12.57192 > 239.255.255.250.1900: UDP, length 146
04:14:08.626959 IP 192.168.1.12.57193 > 239.255.255.250.1900: UDP, length 146
04:14:08.735127 IP 192.168.1.12.57192 > 239.255.255.250.1900: UDP, length 146
04:14:08.735919 IP 192.168.1.12.57193 > 239.255.255.250.1900: UDP, length 146
04:14:46.199867 IP 192.168.1.12.63109 > 239.255.255.250.1900: UDP, length 175
04:14:47.203277 IP 192.168.1.12.63109 > 239.255.255.250.1900: UDP, length 175
04:14:48.211499 IP 192.168.1.12.63109 > 239.255.255.250.1900: UDP, length 175
04:14:49.219718 IP 192.168.1.12.63109 > 239.255.255.250.1900: UDP, length 175
04:15:00.236111 IP 192.168.1.11.60661 > 239.255.255.250.1900: UDP, length 175
04:15:01.230264 IP 192.168.1.11.60661 > 239.255.255.250.1900: UDP, length 175
04:15:02.224154 IP 192.168.1.11.60661 > 239.255.255.250.1900: UDP, length 175
04:15:03.216578 IP 192.168.1.11.60661 > 239.255.255.250.1900: UDP, length 175
04:15:08.081743 IP 192.168.1.12.57192 > 239.255.255.250.1900: UDP, length 146
04:15:08.082596 IP 192.168.1.12.57193 > 239.255.255.250.1900: UDP, length 146
04:15:08.190270 IP 192.168.1.12.57192 > 239.255.255.250.1900: UDP, length 146
04:15:08.191062 IP 192.168.1.12.57193 > 239.255.255.250.1900: UDP, length 146
04:15:08.298676 IP 192.168.1.12.57192 > 239.255.255.250.1900: UDP, length 146
04:15:08.299092 IP 192.168.1.12.57193 > 239.255.255.250.1900: UDP, length 146
04:16:07.661239 IP 192.168.1.12.57192 > 239.255.255.250.1900: UDP, length 146
04:16:07.662039 IP 192.168.1.12.57193 > 239.255.255.250.1900: UDP, length 146
04:16:07.769118 IP 192.168.1.12.57192 > 239.255.255.250.1900: UDP, length 146
04:16:07.769920 IP 192.168.1.12.57193 > 239.255.255.250.1900: UDP, length 146
04:16:07.877713 IP 192.168.1.12.57192 > 239.255.255.250.1900: UDP, length 146
04:16:07.878513 IP 192.168.1.12.57193 > 239.255.255.250.1900: UDP, length 146
04:16:21.929169 IP 192.168.1.12.138 > 192.168.1.255.138: UDP, length 201
04:16:45.343058 IP 192.168.1.12.63110 > 239.255.255.250.1900: UDP, length 175
04:16:46.345834 IP 192.168.1.12.63110 > 239.255.255.250.1900: UDP, length 175
04:16:47.354047 IP 192.168.1.12.63110 > 239.255.255.250.1900: UDP, length 175
04:16:48.362302 IP 192.168.1.12.63110 > 239.255.255.250.1900: UDP, length 175
04:16:59.364256 IP 192.168.1.11.60269 > 239.255.255.250.1900: UDP, length 175
04:17:00.358403 IP 192.168.1.11.60269 > 239.255.255.250.1900: UDP, length 175
04:17:01.351801 IP 192.168.1.11.60269 > 239.255.255.250.1900: UDP, length 175
04:17:02.344788 IP 192.168.1.11.60269 > 239.255.255.250.1900: UDP, length 175
04:17:07.208894 IP 192.168.1.12.57192 > 239.255.255.250.1900: UDP, length 146
04:17:07.209694 IP 192.168.1.12.57193 > 239.255.255.250.1900: UDP, length 146
04:17:07.317157 IP 192.168.1.12.57192 > 239.255.255.250.1900: UDP, length 146
04:17:07.317944 IP 192.168.1.12.57193 > 239.255.255.250.1900: UDP, length 146
04:17:07.425766 IP 192.168.1.12.57192 > 239.255.255.250.1900: UDP, length 146

^C
60 packets captured
60 packets received by filter
0 packets dropped by kernel

A tcpdump -i br-lan ip will include all WLAN traffic. Filtering tcpdump -i br-lan ip and ! host 192.168.1.1 and ! host 192.168.1.103 looks the same as the example above. The same is true for tcpdump -i eth0.1 ip.

Multicast/broadcast packets are seen, but traffic between PC1 and PC2 is invisible.

Thanks... yes, probably just how things come across when you mix different cultures + text only communication methods. I'm American, for whatever that's worth... lol

You are really overcomplicating the situation here, IMO. I use the 802.1q definition of VLANs.
I now understand a bit about what you mean by having the same subnet on different VLANs -- but the thing is, that's not how VLANs are meant to work. You're simply using 802.1q tags to (virtually) physically isolate two networks. But there will be no way to route between those two networks because they have the same subnet (and as an aside, but relevant, using the 'wrong' subnet on VLAN 2 means the router isn't going to be able to actually participate in the connections anyway -- more later). If you can show me a working configuration and prove me wrong about this, I'd love to learn how this can be done.

The isolation you see is not firewall based (because it is not routed)... it is simply that there is no way to route across 2 networks that have the same subnet, so it's not happening as a routed operation. It's purely 802.1q based switching isolation.

So your results show that your network works for all of the scenarios I would expect. And the failures also make sense because you're using 802.1q methods only for switching in your situation -- it will never be possible to route between two identical subnets that are 802.1q isolated, ever.

But it is... configured as I said... it's right in your network configuration here:

If you plug a device into the ports associated with VLAN 2 and you use a subnet that is not 192.168.2.0/24 (i.e. you've been connecting a computer assigned to the the 192.168.1.0/24 subnet), it will never route anywhere, and it will not be able to connect to VLAN1 or anything outside the 802.1q switching realm. And, it will only be able to connect with other systems on that same subnet (192.168.1.0/24) as a purely switched network since the router will not be part of that network at all (since it is on the 192.168.2.0/24 subnet). No routing will be possible if the router and the other host don't belong to the same network (192.168.2.0/24 on VLAN 2; 192.168.1.0/24 on VLAN 1).

I sincerely believe that your entire premise will never work. I'd love to learn how to do this if you do achieve the routing, but I'm quite confident that I am correct here (and I'll fully admit if I'm wrong if/when you do show me evidence of your schema working).

1 Like

Just as a heads up:

Completely new development happening!

More later, I want to investigate a bit further first.

[Spoiler: It isn't working "out of the box", but I found a workaround to make it work as it is supposed to.]

I'm sorry for the late response, but since the issue was solved, suddenly other things had a higher priority.

I’m also not quite sure how to structure the response, because by now it needs three different responses. I guess, I’ll simply address each of them individually.

Thank you for your help and your support. I honestly mean it.

But please be also aware, that nothing you’ve said, pointed me in the right direction. All the questions you’ve asked were answered in the original post.

I’ve mentioned in the original post, that I am new to OpenWrt and this forum, but that the problem isn’t about being new. I do have some background knowledge when it comes to “this kinda computer stuff”.

And please don’t let cultural difference get in the way. You did help me, by confirming that my configuration is fine.

You’ve tried to check on the communication between devices, while my original post already included a statement, that they can communicate fine. I do understand why you've asked and appreciate it and even checked a fourth time out of respect.

You’ve tried to relate the problem to the VLAN discussion, we’ve had on the side. I’ve mentioned many times that the VLAN discussion has nothing to do with the issue. And examples in the VLAN discussion are just examples and the real configuration is still the same as in the original post. And at that point, I kinda loose the understanding part, because I've made, on several occasions, very clear that my issue isn't related to VLAN.

Before I go on: I am currently running my MF286+ with a configuration that is basically the same as the original post… (different IP addresses, some more Wi-Fi stuff) ...and it is running perfectly fine.

Please try to understand the meaning before emotions kick in, and maybe try to understand it again, when the emotions cooled down: I appreciate your help, but you are led by a huge expectation bias. There are probably reasons for it, but it makes your life and that of others more difficult. Example: VLAN. The entire VLAN discussion started, because I've confirmed, that VLAN isn't the problem. And we ended up, you’re questioning if my understanding of VLAN and my setup might cause the troubles I've had. Again: I've only mentioned that VLAN is working as expected and IS NOT the problem. In your defense, the problem is far from where you've imagined it to be. So, your investigation is understandable. Yet, I've mentioned a couple of times, that the problem is located somewhere else. Even stating, that I believe the problem to be between the CPU and the physical port. And that's exactly where the problem is. I'd say the driver or the driver implementation. Your inability to listen to these points raised is called “bias”. And there are many forms of bias (that we all like to ignore because they are against our nature), but because you've expected something, but the result didn't match your expectation, I think it is expectation bias.

For me, I'm fine. You did help by confirming my config is fine. Thank you for your help and your time.

  • I was talking about three parts. This was part One. Part Two is about routing between networks with the same address range. And Part Three will be about the actual problem(s) and how to resolve (work around) them.

I'm glad I was able to help.

I don't intend to. Once we had set the expectations, I knew that what I might read as terse was really just directness. All good here.

I think you're making some assumptions about my emotions here -- I've taken the position (from a non-emotional, logic based state) that I don't believe that your original problem description is solvable (btw, I'm an engineer -- I find truth in the saying "the fastest way to get an engineer to solve a problem is to tell them that it is unsolvable"). I'm totally willing to be proven wrong -- I take it as a learning opportunity, not an insult to my ego.

I'm looking forward to your solution. I don't see this as a driver or driver implantation issue because I also assert that the problem would be the same on any platform that is standards based (be it Cisco, 'Tik, Ubiquiti, Aruba, TP-Link, Netgear, etc.).

I am aware of bias. This doesn't need to be explained. However, it is possible that the problem statement wasn't well communicated (if it was on your end) or well understood (if it was on my end).

This is, fundamentally, what I believe not to be possible (at least not without an intermediate address translation in the mix).

I'm looking forward to seeing your solution. And I'll even be willing to try to duplicate your configuration and confirm or refute the results. If the solution works, I will have learned something and I will be able to share that with others. [EDIT: If you search the forums, you will find a bunch of examples of me retracting my statements when I have learned that I was incorrect. I often leave them up but add an edit and strikethrough the incorrect bits to make it really clear and obvious. I do this for two reasons: 1) I know I am not infallible, so I'll be wrong sometimes -- that's okay in my mind, and I will own it, correct the bad info, and learn from it. 2) I hope that keeping my posts up will help others who might have the same incorrect understanding, or at the very least ensure that the context of other parts of the thread is preserved but corrected where I was wrong.]

And, with your explanations in parts 2 and 3, maybe that will clear up any misunderstandings I might have had with your problem statement.

I'll be busy over the next few days -- I should be able to read your posts, but it is possible I won't be able to test or reply to them for a bit.