IPv6 Link local...
1 Like
I understand that it would seem ideal if a diagram were provided, but the topology is actually quite simple to understand. The OpernWrt device switches a local network. A router separates the local network from an upstream network, designated as 192.168/16, which also features a default gateway for NAT with the ISP.
The leading standard overwhelmingly is 192.168.1.1, and the widespread alternatives are also limited, in comparison to the size of an abstract space of possibilities, to be guessed arbitrarily.
I prefer for one value to hold indefinitely.
The switch is an important endpoint in the network, preferably reachable by an address assigned statically.
Anyone familiar with provisioning such devices should succeed in making some connection to the administrative portal within the course of a leisurely Sunday afternoon, without relying on earlier records.
I can think of many, and so can you. Many, many more are obviously possible.
As explained, the interface is assigned 192.168.1.1/16, and the other interfaces are assigned a static address particular to the subnet.
So to be clear, there is exactly one router (or at least one device being used as a router) with a lan subnet of 192.168.0.0/16, and an upstream (wan) that is internet facing. There are no other routers in the system, correct? And no other network subnets (at one point you mentioned a 10.something subnet being used)?
Yes, it's the 'overwhelming standard' but it's also the cause of lots of problems such as when people have overlapping subnets or IP collisions.
What is the address of the router serving this network?
That's just senseless in the context of networking. I just don't understand why putting a label on the thing is so objectionable?
Why must it be 192.168.1.1?? And, why can't it be 192.168.1.1 on the primary network?
And the two methods I have provided do indeed have static IPs (2 of them, in fact) for you to use to access the device.
So you mean truly anyone? Some random person walks in off the street and you want them to administer this device?
And what about the password?
If you say that you'll just use "password" or leave it blank or something, and you're literally inviting anyone to administer it, how do you propose to prevent them from doing things (intentionally or not) that might knock the device offline or make other changes? For example, who's to say that they wouldn't reassign the IP addresses?
I'll just assume that this means you don't actually understand how networks break and how to troubleshoot them.
So the switch already has this address... what's the point of the secondary interface?
And I'll just come back to this:
No. It is not possible to have the same address on two interfaces.
It is not clear why you'd want two interfaces to have the same address in the first place. If that address is assigned and working on one interface, you don't need a second for a backup.
A static IP on the primary interface will work as long as the basics work (i.e. electrical power is good, the device itself is not experiencing a hardware failure, no misconfigurations, etc.). This will still work even if the primary router goes down. If those basics don't work, chances are a secondary network interface isn't going to help you.
Why do you insist on something that is clearly both bad practice and not going to work??
The 192.168. network is intermediary to the internet NAT router, and a basic router providing access to a 10.4. network. The OpenWrt device is on the 10.4. network, providing wireless access, and is assigned a static address, which is used for administrative access to the device.
To be clear, the case being discussed in not of the same address being assigned to different interfaces of the same device.
root@cpe:~# ip -br -4 a | sort -V
br-vlan.16@br-vlan UP 192.168.16.1/24
br-vlan.17@br-vlan UP 192.168.17.1/24
br-vlan.24@br-vlan UP 192.168.24.1/24
br-vlan.49@br-vlan UP 192.168.49.1/24
br-vlan.56@br-vlan UP 192.168.56.1/24
br-vlan.64@br-vlan UP 192.168.64.1/24
br-vlan.65@br-vlan UP 192.168.65.1/24
br-vlan.71@br-vlan UP 192.168.71.1/24
br-vlan.76@br-vlan UP 192.168.76.1/24
br-vlan.77@br-vlan UP 192.168.77.1/24
lo UNKNOWN 127.0.0.1/8 192.168.0.1/32
wg0 UNKNOWN 192.168.240.1/24
wg15 UNKNOWN 192.168.255.1/24
root@cpe:~# for VLAN in 16 17 24 49 56 64 65 71 76 77; do ip addr add 192.168.0.1/32 dev br-vlan.${VLAN}; done
root@cpe:~# ip -br -4 a | sort -V
br-vlan.16@br-vlan UP 192.168.16.1/24 192.168.0.1/32
br-vlan.17@br-vlan UP 192.168.17.1/24 192.168.0.1/32
br-vlan.24@br-vlan UP 192.168.24.1/24 192.168.0.1/32
br-vlan.49@br-vlan UP 192.168.49.1/24 192.168.0.1/32
br-vlan.56@br-vlan UP 192.168.56.1/24 192.168.0.1/32
br-vlan.64@br-vlan UP 192.168.64.1/24 192.168.0.1/32
br-vlan.65@br-vlan UP 192.168.65.1/24 192.168.0.1/32
br-vlan.71@br-vlan UP 192.168.71.1/24 192.168.0.1/32
br-vlan.76@br-vlan UP 192.168.76.1/24 192.168.0.1/32
br-vlan.77@br-vlan UP 192.168.77.1/24 192.168.0.1/32
lo UNKNOWN 127.0.0.1/8 192.168.0.1/32
wg0 UNKNOWN 192.168.240.1/24
wg15 UNKNOWN 192.168.255.1/24
root@cpe:~# ip -4 r
unreachable 10.0.0.0/8 proto bird metric 32
unreachable 100.64.0.0/10 proto bird metric 32
unreachable 169.254.0.0/16 proto bird metric 32
unreachable 172.16.0.0/12 proto bird metric 32
unreachable 192.0.2.0/24 proto bird metric 32
unreachable 192.88.99.0/24 proto bird metric 32
unreachable 192.168.0.0/16 proto bird metric 32
192.168.0.1 dev lo proto bird scope link metric 32
192.168.16.0/24 dev br-vlan.16 proto kernel scope link src 192.168.16.1
192.168.16.0/24 dev br-vlan.16 proto bird scope link metric 32
192.168.17.0/24 dev br-vlan.17 proto kernel scope link src 192.168.17.1
192.168.17.0/24 dev br-vlan.17 proto bird scope link metric 32
192.168.24.0/24 dev br-vlan.24 proto kernel scope link src 192.168.24.1
192.168.24.0/24 dev br-vlan.24 proto bird scope link metric 32
192.168.49.0/24 dev br-vlan.49 proto kernel scope link src 192.168.49.1
192.168.49.0/24 dev br-vlan.49 proto bird scope link metric 32
192.168.56.0/24 dev br-vlan.56 proto kernel scope link src 192.168.56.1
192.168.56.0/24 dev br-vlan.56 proto bird scope link metric 32
192.168.64.0/24 dev br-vlan.64 proto kernel scope link src 192.168.64.1
192.168.64.0/24 dev br-vlan.64 proto bird scope link metric 32
192.168.65.0/24 dev br-vlan.65 proto kernel scope link src 192.168.65.1
192.168.65.0/24 dev br-vlan.65 proto bird scope link metric 32
192.168.71.0/24 dev br-vlan.71 proto kernel scope link src 192.168.71.1
192.168.71.0/24 dev br-vlan.71 proto bird scope link metric 32
192.168.76.0/24 dev br-vlan.76 proto kernel scope link src 192.168.76.1
192.168.76.0/24 dev br-vlan.76 proto bird scope link metric 32
192.168.77.0/24 dev br-vlan.77 proto kernel scope link src 192.168.77.1
192.168.77.0/24 dev br-vlan.77 proto bird scope link metric 32
192.168.240.0/24 dev wg0 proto kernel scope link src 192.168.240.1
192.168.240.0/24 dev wg0 proto bird scope link metric 32
192.168.240.1 dev wg0 proto bird scope link metric 32
192.168.255.0/24 dev wg15 proto kernel scope link src 192.168.255.1
192.168.255.0/24 dev wg15 proto bird scope link metric 32
192.168.255.1 dev wg15 proto bird scope link metric 32
unreachable 198.18.0.0/15 proto bird metric 32
unreachable 198.51.100.0/24 proto bird metric 32
unreachable 203.0.113.0/24 proto bird metric 3
Like I said... a topology diagram would help. You seem reluctant to provide one, but it will almost certainly clarify the things you've been describing.
There are two things here...
-
You've made statements that seem to imply that the switch/AP is currently using 192.168.1.1/16 on its primary interface. It's extremely difficult to understand, though, because you have been surprisingly vague about critical details and you won't provide a topology diagram.
-
Even if it is a different IP address than is being used on the primary interface, it will not work if the subnets overlap. This is 100% guaranteed to be a problem since you are trying to use 192.168.1.1 on a secondary interface when you have a 192.168.0.0/16 network on a primary interface.
As I (and others) have stated numerous times, it is an invalid configuration to have overlapping subnets on different interfaces. But... you seem extremely insistent, so go ahead and do it. If it doesn't actually break things, feel free to use the invalid configuration at your own risk (it might not work the way you want when you need it most). However, there is a reasonable probability that it will actually break things... but go ahead and try to find out if I'm wrong about this fact.
Ultimately, though, I think that your goal is entirely nonsensical. It make zero sense to insist on a specific IP address just because it's common... instead, you can simply put a label on the device with the actual IP. It is also extremely unusual (and very likely dangerous) to allow literally anybody to login to this device to "administer" it. And you've stated no specifics about the types of failure conditions that might require to someone needing to login to this device in the first place, rather saying that "the gamut is essentially boundless." This leads me to believe that you really have no idea how to plan for, diagnose, or troubleshoot network issues (including the one that you are about to create).
As I have said, though... go ahead and try it. Just don't say you weren't warned.
1 Like
I am not intending to make a diagram illustrating a case so trivial.
There are two private subnets, 192.168. and 10.4. The former is situated intermediary to the latter and the uplink to the ISP.
The internet gateway is 192.168.1.1, through a device separate from the one running OpenWrt, and on a separate subnet.
The same address, 192.168.1.1, is provisioned on the device running OpenWrt, for the interface designated by the the first Ethernet interface. This interface, however, is disconnected while the device is functioning for its normal use, of providing wireless access to 10.4, through its other interfaces configured as a bridge.
It is only connected when the device is pulled from all its other connections, in the case that the device or the network overall is not functioning as intended.
Essentially, what is needed is for the one Ethernet interface to be completely partitioned from the others, in terms of routing. It should with them only access to the administrative portal.
It might be trivial, but your explanations are unclear, so without a diagram, it is very hard to decipher.
You had previously said that there was only one router. This sounds like two.
Your description remains unclear.
It seems like you have already setup this secondary interface?? So I am not sure what you are asking.
I think Iām done here, though. Good luck!
2 Likes
The topology is sufficiently trivial that a diagram is unlikely to add any further insights or elucidation.
I am sorry you feel dissatisfied with my explanations, but considering as much, any diagram I might produce is unlikely to foster stronger satisfaction.
I believe I mentioned a router performing NAT with the ISP, and another node performing basic routing between two local subnets.
I never insisted "there was only one router".
For someone seeking assistance you do seem to be trying awfully hard to make it tricky for people to assist. A simple diagram can bring a clarity that can be difficult to achieve even with 'clear' text descriptions. It's also not something that is requested on a whim or to waste people's time.
But, if a diagram is out of the question, how about the current config details from the device? What's the output of the following commands?:
cat /etc/config/network
cat /etc/config/firewall
cat /etc/config/dhcp
cat /etc/config/wireless
nft list ruleset
ip -4 addr; ip -4 ro li tab all; ip -4 ru
Post using the "Preformatted text </>" button:
Remember to redact passwords, MAC addresses and any public IP addresses you may have
1 Like
I understand that some might find a diagram helpful, but the topology is quite triivial, and the other participant seemed more determined not to understand, regardless, than sincere in trying to understand.
Even if some may be deterred from answering due to the absence of a diagram, I feel the explanations are adequate to support general discussion.
$ cat /etc/config/network
config interface 'loopback'
option ifname 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option packet_steering '1'
option ula_prefix 'fdf9:289f:7425::/48'
config interface 'lan'
option type 'bridge'
option proto 'static'
option ip6assign '60'
option ipaddr '10.4.1.3'
option netmask '255.255.0.0'
option gateway '10.4.1.2'
list dns '10.4.1.2'
option ifname 'lan2 lan3 lan4'
config interface 'wan'
option ifname 'wan'
option proto 'dhcp'
config interface 'wan6'
option ifname 'wan'
option proto 'dhcpv6'
config interface 'wwan'
option proto 'dhcp'
config interface 'admin'
option proto 'static'
option ifname 'lan1'
option ipaddr '192.168.1.1'
option type 'bridge'
option netmask '255.255.0.0'
$ 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 'wan'
option input 'REJECT'
option output 'ACCEPT'
option forward 'REJECT'
option masq '1'
option mtu_fix '1'
list network 'wan'
list network 'wan6'
list network 'wwan'
config forwarding
option src 'lan'
option dest 'wan'
config rule
option name 'Allow-DHCP-Renew'
option src 'wan'
option proto 'udp'
option dest_port '68'
option target 'ACCEPT'
option family 'ipv4'
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 src_ip 'fc00::/6'
option dest_ip 'fc00::/6'
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'
config rule
option name 'Support-UDP-Traceroute'
option src 'wan'
option dest_port '33434:33689'
option proto 'udp'
option family 'ipv4'
option target 'REJECT'
option enabled 'false'
config include
option path '/etc/firewall.user'
config zone
option name 'admin'
option input 'ACCEPT'
list network 'admin'
option output 'ACCEPT'
option forward 'ACCEPT'
config zone
option name 'admin_up'
option output 'ACCEPT'
option forward 'REJECT'
option masq '1'
list network 'lan'
option input 'REJECT'
config forwarding
option src 'admin'
option dest 'admin_up'
$ 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 dhcpv4 'server'
option ra_slaac '1'
list ra_flags 'managed-config'
list ra_flags 'other-config'
option ignore '1'
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'
config dhcp 'admin'
option interface 'admin'
option start '100'
option limit '150'
option leasetime '12h'
$ cat /etc/config/wireless
config wifi-device 'radio0'
option type 'mac80211'
option channel '11'
option hwmode '11g'
option path '1e140000.pcie/pci0000:00/0000:00:01.0/0000:02:00.0'
option htmode 'HT20'
option cell_density '0'
option country '<REDACTED>'
config wifi-iface 'default_radio0'
option device 'radio0'
option network 'lan'
option mode 'ap'
option ssid '<REDACTED>'
option encryption 'psk-mixed'
option key '<REDACTED>'
config wifi-device 'radio1'
option type 'mac80211'
option hwmode '11a'
option path '1e140000.pcie/pci0000:00/0000:00:01.0/0000:02:00.0+1'
option htmode 'VHT80'
option cell_density '0'
option country '<REDACTED>'
config wifi-iface 'default_radio1'
option device 'radio1'
option network 'lan'
option mode 'ap'
option ssid '<REDACTED>'
option encryption 'psk-mixed'
option key '<REDACTED>'
config wifi-iface 'wifinet4'
option device 'radio0'
option mode 'mesh'
option encryption 'sae'
option mesh_id '<REDACTED>'
option mesh_fwding '1'
option mesh_rssi_threshold '0'
option key '<REDACTED>'
option network 'lan'
config wifi-iface 'wifinet5'
option device 'radio1'
option mode 'mesh'
option encryption 'sae'
option mesh_id '<REDACTED>'
option mesh_fwding '1'
option mesh_rssi_threshold '0'
option key '<REDACTED>'
option network 'lan'
config wifi-iface 'wifinet6'
option device 'radio0'
option mode 'ap'
option encryption 'psk2'
option hidden '1'
option key '<REDACTED>'
option network 'admin'
option ssid '<REDACTED>'
$ nft list ruleset
-ash: nft: not found
$ ip -4 addr; ip -4 ro li tab all; ip -4 ru
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
10: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
inet 10.4.1.3/16 brd 10.4.255.255 scope global br-lan
valid_lft forever preferred_lft forever
23: br-admin: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
inet 192.168.1.1/16 brd 192.168.255.255 scope global br-admin
valid_lft forever preferred_lft forever
10.4.0.0/16 dev br-lan scope link src 10.4.1.3
192.168.0.0/16 dev br-admin scope link src 192.168.1.1
broadcast 10.4.0.0 dev br-lan table local scope link src 10.4.1.3
local 10.4.1.3 dev br-lan table local scope host src 10.4.1.3
broadcast 10.4.255.255 dev br-lan table local scope link src 10.4.1.3
broadcast 127.0.0.0 dev lo table local scope link src 127.0.0.1
local 127.0.0.0/8 dev lo table local scope host src 127.0.0.1
local 127.0.0.1 dev lo table local scope host src 127.0.0.1
broadcast 127.255.255.255 dev lo table local scope link src 127.0.0.1
broadcast 192.168.0.0 dev br-admin table local scope link src 192.168.1.1
local 192.168.1.1 dev br-admin table local scope host src 192.168.1.1
broadcast 192.168.255.255 dev br-admin table local scope link src 192.168.1.1
0: from all lookup local
32766: from all lookup main
32767: from all lookup default
What version of OpenWrt is this? The syntax is unusual.
ubus call system board
$ ubus call system board
{
"kernel": "5.4.108",
"hostname": "openwrt-base",
"system": "MediaTek MT7621 ver:1 eco:3",
"model": "CUDY X6",
"board_name": "cudy-x6",
"release": {
"distribution": "OpenWrt",
"version": "21.02-SNAPSHOT",
"revision": "r15949-b2c9a8741f",
"target": "ramips/mt7621",
"description": "OpenWrt 21.02-SNAPSHOT r15949-b2c9a8741f"
}
}
This version is unsupported. It has been eol for quite a while now and has many known security vulnerabilities. The syntax in your config is very unusual and probably incorrect, even when the firmware was current and up to date.
Please upgrade. The upgrade will require that you reset to defaults. Failing to do so will soft-brick the device.
https://firmware-selector.openwrt.org/?version=23.05.5&target=ramips%2Fmt7621&id=cudy_x6-v1
1 Like
Is there no way to upgrade without cleanly preserving the settings?
Would you please expand on your comment about the scenario leading to a bricked device?
If you blindly apply old settings there are changes you soft-brick the devices.
Which means, the devices does not operate in a well defined state.
If your device supports it, you can however boot into fail-safe and reflash the device or just fix a bogus config.
But still, sysupgrade without -n (do not safe config) is kinda risky if you move versions. Remember these little cheap plastic boxes are no full blown PC with a "proper" OS. In the end of the day they are embedded devices and should be treated as such.
Write your configs for the current Version; test these; and in the end apply them.
1 Like
Concretely, what is the most reliable and straightforward method for introducing the appropriate firmware, and then applying the earlier custom configuration (e.g. address assignment, interface bridging, SSID definitions, routing rules)?
I have minimal experience, and wish to be able to restore full functionality as readily as possible, from the point of the device going offline from usual operation.
How do add-on packages (e.g. for WPA3 and 802.11s) feature within such a process?
It is worth noting that your config does not seem to match the description of your network topology -- the upstream network (lan) appears to be 10.4.0.0/16, whereas the alternate (admin) is 192.168.0.0/16.
You had previously described an upstream network of 192.168.0.0/16, but I'm not seeing that in the config as shown. This is yet one more reason that a diagram, as simple as it might have been, would have clarified so much confusion.
With that in mind:
- you do need to upgrade and do not keep settings (reset to defaults) during the upgrade process. There are many problems with the config as it exists right now, and it would result in a soft-brick if you upgrade and keep settings.
- If the lan is indeed 10.4.0.0/16, there is no conflict if you choose to use 192.168.1.1 as the local address for the admin network interface.
- Based on the current configuration, there is zero reason for you to use 192.168.0.0/16. Instead, use 192.168.1.0/24.
Address assignment is simple... change the lan address as shown here. Do not forget to disable the DHCP server on the lan.
Bridging is already setup by default. You don't need to change anything immediately... but we'll do some adjustments (and we can help you with that) to separate one of the lan ports. I think the new version of firmware will be using DSA, so that will mean bridge-vlans.
There is no real routing to worry about here, unless you want the admin network to be able to route upstream. But if that admin network is used only for emergency/recovery situations, you don't need to route. The rest is all L2 switching, so routing is entirely irrelevant on this device.
If you want to do it right, you need to listen carefully to our advice and take it step by step.
WPA3 is already available standard in 23.05. And 802.11s can be added, if it is actually necessary by installing the appropriate packages. However, 802.11s probably doesn't apply here unless you have multiple APs and the rest are all connecting wirelessly. This is the first time you're even mentioning 802.11s.
1 Like
Whether the current configuration is most optimal or correct is ancillary to the question of pursuing a clean upgrade.
The simple fact is that the device presently meets my needs immeasurably better than would a device having been just rest to defaults, including by its now properly acting as a mesh node, and an automated process for restoring the custom configuration would be significantly faster, and generally more reliable, than one fully manual.
I have no inclination needlessly to start from scratch, simply because particular changes may be indicated.
Is it possible to save the settings in a high-level form (e.g. a text dump capturing the changes previously introduced manually), that could be reapplied to the system once the device is reset with new firmware?