Tested on SNAPSHOT and 25.12.0-rc3. Even when using the firmware-selector.openwrt.org (uci-defaults) tool, when changing the IP address from 192.168.1.1 to, for example, 192.168.10.1, compiling the firmware, and flashing the router firmware, it becomes unavailable on both the local and global network (no internet access). On the local network, an IPv6 address is obtained, but not an IPv4 address. The same issue occurs when using custom UCI strings, which work fine on other routers. The same issue occurs on the ImmortalWrt snapshot. The router must be restored via TFTP.
What happens if you use the standard/default image of 25.12.0rc3? Does it work properly?
Without using UCI, the image works as expected, even if you add your own packages. It builds and works, but if you add anything, even through the standard UCI, it builds but then doesn't work.
The AI says there's something wrong with the interface names on this model, but I'm not a programmer and can't confirm anything. I just discovered it and reported it.
Good. So we can rule out issues with the base image.
Please show us specifically what you're adding.
Don't rely on AI for anything related to OpenWrt. It has been proven many times over to be wrong almost all the time.
Did you use AI to generate your UCI changes?
EDIT: It would probably be a good thing to also post the respective files for things you are changing (such as /etc/config/network) in the default state as it shows up from the normal/default image.
1 Like
Naturally, I don't rely on AI))).
I ran another experiment.
In the packages window, I removed "basic" from the wpad-basic-mbedtls package, getting wpad-mbedtls. In the uci-defaults window, I removed the # from the IP address line, getting lan_ip_address="192.168.1.1", which I changed to 192.168.10.1. I simply added 0 without changing the syntax, compiled the firmware, flashed the router, and it died. The symptoms are the same as in the message above.
The file you requested after restoring the router is a file compiled using the openwrt command and downloaded from the link at firmware-selector.openwrt.org
i.s. the firmware file without any changes.
Summary
config interface 'loopback'
option device 'lo'
option proto 'static'
list ipaddr '127.0.0.1/8'
config globals 'globals'
option dhcp_default_duid '00045f20e257bc0d4f1a98d10c2e7f5337f4'
option ula_prefix 'fdb8:e15a:5b84::/48'
config device
option name 'br-lan'
option type 'bridge'
list ports 'lan'
config interface 'lan'
option device 'br-lan'
option proto 'static'
list ipaddr '192.168.1.1/24'
option ip6assign '60'
config interface 'wan'
option device 'wan'
option proto 'dhcp'
config interface 'wan6'
option device 'wan'
option proto 'dhcpv6'
What happens if you change the IP address on the working standard image? Does it still cause the device to become unreachable?
Do you have a serial connection to the router? If so, can you show the config file that results after the UCI change (with the firmware selector)?
If no serial connection is available, does the system manage to provide a DHCP lease to your computer?
Luci doesn't let me change it. I can only delete or add it. I deleted 192.168.1.1 and added 192.168.10.1. I applied it, and everything worked fine. I access the router via cable at the new address 192.168.10.1.
/etc/config/network - after the change.
Summary
config interface 'loopback'
option device 'lo'
option proto 'static'
list ipaddr '127.0.0.1/8'
config globals 'globals'
option dhcp_default_duid '00049a3d6bad5dea4d5da7389a280ccf6458'
option ula_prefix 'fdfe:7ef2:6f3::/48'
option packet_steering '1'
config device
option name 'br-lan'
option type 'bridge'
list ports 'lan'
config interface 'lan'
option device 'br-lan'
option proto 'static'
option ip6assign '60'
list ipaddr '192.168.10.1/24'
config interface 'wan'
option device 'wan'
option proto 'dhcp'
config interface 'wan6'
option device 'wan'
option proto 'dhcpv6'
P.S. I have a UART, but since the router isn't mine and I'm seeing it for the first time and don't know how to disassemble it without leaving any visible traces, I'd rather not do that))).
I just came up with a theory.
I think that 25.10 moves to CIDR notation instead of the old subnet mask. This means that the address you set in uci needs to be192.168.10.1/24 or similar.
My guess is that when you change the address in the firmware selector custom image, it is doing what you set, but results in no subnet mask/size being defined.
So try including the /24 in that line when maingthe custom image.
2 Likes
And it worked!!! I added /24, got
lan_ip_address="192.168.10.1/24"
I compiled the firmware and it worked!!!))).
I wonder how you'll solve this widespread problem?
It's already RC3, and until you kick it, it won't work))).
I'm not ready to tick the "Solution" box.
Woo hoo!
The good news is that this is not an issue with 25.12.
Technically, this counts as a 'user error' but believe me when I say that this is not intended to be condescending in any way. I would have made exactly the same mistake.
The reason I say it is a user error is that the change of the IP address you described initially did not include a required piece of information -- the subnet size. This wasn't a parsing error or a bug, but rather the result of not defining the subnet properly.
But... all of that said... the real problem is that the example values in the firmware selector don't include the subnet size either, so anyone using that script (you, me, anyone...) would likely make the same mistake.
The best way to solve this is to update the firmware selector's example value to include the /24 subnet size and/or to add comments around that line to ensure that users know that this is a requirement.
@efahl and/or @aparcar should be able to update the relevant file that provides the example values and script.
1 Like
If anyone needs a 10.X or 172.X subnet...
Of course, this might be necessary starting with version 25, but it's been working for many, many years now, including on 24.X, without /24.
It won't be fast)).
Yeah... so to be more explicit about what I do and do not know about the situation...
What I know:
- The same issue would have occurred had you edited the lan IP directly in a running config (such as UCI CLI or direct text file edits) and had omitted/removed the subnet mask/size. The problem is just the missing (but absolutely critical) subnet information. This is true on all versions, although the method by which it is defined might vary.
- 24.10 and earlier have (in the default config) the subnet mask as a specific line in the config stanza.
- 24.10 accepts the CIDR slash notation
- 25.12 specifically omits the subnet mask statement and uses CIDR slash notation in the default configuration.
What I don't (yet) know:
- Will 25.12 still accept the old subnet mask statements in lieu of the CIDR notation, or does it specifically require CIDR slash notation?
- What version of OpenWrt was the first that accepted the CIDR slash notation in general? (I know for fact that 24.10 does, but I honestly never really paid attention to when this first appeared).
- I have never tested what happens if both a subnet mask and CIDR slash exist within the same network config stanza (for versions that support both methods)... does it cause errors or does one take priority (if so, which one, or how is it decided)?
- And what happens both methods are used but they disagree about the subnet size? For example if the CIDR slash defines a /16 but the subnet mask defines a /24 like below:
config interface 'lan'
option device 'br-lan'
option proto 'static'
option ip6assign '60'
list ipaddr '10.20.0.1/16'
option netmask '255.255.255.0'
The reason that all of these considerations are important is that it may affect the way this is handled in the firmware selector's example script values since the script may need logic to ensure that the subnet is properly defined, especially if the CIDR slash notation is applied to the address line in the script on 24.10 or earlier.
All of this does become a bit less of a concern if the firmware selector's custom image generation tool can provide a sample script/value set that is tailored to the selected version of OpenWrt... so 24.10 and earlier get the existing samples, but 25.12 and later have the CIDR example value.
OK! Let's hope they found it in time. Now all that's left is for a neat solution to be found just as quickly, and for no one else to even know there was a issue.
1 Like
I just posted the issue in the firmware selector thread (linking back to this one)... hopefully this will be an easy fix.
2 Likes
@psherman I might be mistaken but I had to migrate my setup scripts to CIDR a while ago (pre 24.10 even).
Of course, if it's not documented...
1 Like
Comment here or on the PR if you want other changes:
2 Likes
Thanks @efahl! Fast work (and fortunately simple fix).
Does this PR apply only to the firmware selector when 25.12 is chosen? If so, this fix should be all that is necessary. But, if this is also applied to 24.10 and earlier as well, isn't the subnet mask defined as a separate line in the defaults for those versions? and what happens if it's defined as a subnet mask + CIDR? And what if the two don't agreee?
1 Like
24.10.5 everything worked as usual for me – flawlessly. Yesterday, I was building it for a CMCC RAX3000Me router. And on the website, I simply inserted a regular IP address in the script, and everything worked. This only applies to the LAN interface address. Personally, I don't need more than that.