SOLVED: Can recovery 192.168.1.1 be changed?

Installing and Using OpenWrt
1

I'm having a problem I cannot understand so am just trying some different things to isolate it.

Using image builder, I build an image. Nothing wrong with the image, it installs, boots, all runs fine.
The only weird thing is that each time I install the firmware and the router reboots, it causes my network to become unusable for 10-20 seconds.

In my build, I have dhcp interfaces only, nothing is static using 192.168.1.1 but each time I re-install the firmware, my network goes down. Note that my local gateway IP is 192.168.1.1 so to me, there is some short lived conflict that occurs just as the new firmware is fired up for the first time.

I know that the recovery IP is 192.168.1.1 so my question is, can I change that IP in my build in order to 100% confirm what is happening. There are a fair number of files that contain the IP so I'm really not sure what to edit to test my idea.

2

You can, if you compile from sources.
Not with imagebuilder, as it "compiles" nothing, but just glues the already compiled core and packages together.

2 Likes
3

Hi,

I've tried using the source builder and it's always over my head.
Is there anything I could do on the router itself then? I guess I could use iptables to maybe block that IP from being used in or out? I just want to test if what I'm seeing is the case.

Or, if someone can confirm what I am seeing as not being unusual, that would be ok too since it only happens once, it doesn't seem to be causing any further problems.

4

You can use the ’uci defaults’ or pre-made configs also with imagebuilder.

3 Likes
5

Failsafe recovery preinit IP is burned into code that is needed well before uci-defaults or config files are read...

2 Likes
6

Yes, but this won't necessarily solve the original issue because the router may/will come up (first time after the flash) with the default address before it runs the scripts to change them and then reboots.

Aside from compiling your own images as @hnyman described, there are three other approaches that can be used:

  1. Keep settings on upgrade. This works for service releases, but is not always an option for major upgrades)
  2. Unplug the router from the main network for that first boot cycle after flashing so that it doesn't collide with your existing router.
  3. Change the network address of your main router (and thus your entire network) so that it is not using 192.168.1.1 (and the 192.168.1.0/24 subnet). There is still a small risk, though, that the DHCP server on the OpenWrt device (enabled by default) could issue a lease to a device on your network that happens to request one during that short period of the first boot cycle, so be aware of this potential issue (it's a low, but non-zero probability).
1 Like
8

On those three options;

1: I'm buying these things used and re-flash them since I don't know and don't care what is on them.
2: I think there are some things that need Internet access when the fw is first started.
3: Not an option, way too much work :).

If this is just the way it works, it's fine, I can deal with that. I was not sure if I was doing something wrong or something weird in the 21.03.x version or something else.

I thought it might be related to the lower layer that contains recovery and wondered if there was a way to change the behavior but it's fine now that I better understand it.

Thank you everyone for the help.

9

Possible solution:
Do not connect the device to your local network.
Use a notebook/PC/whatever that is only connected to the lan connector of the device you are going to flash.

Well, none that i am aware of. Maybe some obscure firmware from more obscure sources, but not OpenWrt.

Well, it's your problem that you'd like to be fixed.

10

So, obviously the upgrade path is not relevant here. However, if you don't know what's on them and/or how they are configured, you shouldn't connect them to your network until after you've installed OpenWrt and appropriately configured it as to not cause conflicts on your network. This would (should) be done with a direct physical connection between the new device and your computer, no other connections whatsoever, with the OpenWrt firmware downloaded onto your computer in advance of this so you can work entirely offline.

No, nothing for OpenWrt requires internet connectivity when it first starts (as already stated by @elder_tinkerer ). Besides, unless connected by the wan port, it would not be possible for the OpenWrt device to gain internet access since it wouldn't be appropriately

This depends on the size of your network, static vs DHCP device assignments, and the like. And, of course, it depends on how often and how seriously your network might be disrupted by this type of situation. In some cases it's actually not that big a deal to make the change, but obviously if you say it is too much work, keep things as they are now. Refer back to my first point about not connecting a new device until it is properly configured.

Good. No, you're not doing anything wrong -- this is expected behavior.

No problem.

If your problem is solved, please consider marking this topic as [Solved]. See How to mark a topic as [Solved] for a short how-to.
Thanks! :slight_smile:

2 Likes
11

I mentioned it's all good folks and thanks for the help, I very much appreciate it.

When I buy used hardware, I always fire it up on a laptop non connected to the network. When I do that, I install my own build so I immediately know what's on the device from that point on.

However, after that, I usually build something more custom for the device then write that to it. At that point, it comes up, causing the issue I mentioned.

The local network is much too complex to change so that is not an option. The answer was pretty simple, letting me know that this is the expected behavior. Knowing that, it is no longer any sort of issue but before knowing, it was a bit of a mystery.

1 Like
12

I always consider 192.168.1.1 as reserved and never use this address in configurations. This allows me to manage my network a lot easier when it comes to resetting or adding new devices.

3 Likes
13

That's a good idea but other than this case I would not see any reason for it.
In all the years I've been using networks, openwrt is the only case I can think of where it's been a problem to have 192.168.1.1 gw.

Anyhow, as it's been said, knowing is the key so it's not even an issue anymore.

14

Given how commonly used 192.168.0.x and 192.168.1.x are among different infrastructure devices, it makes sense to avoid both of them for your own subnets (ideally pick a random one, which is unlikely to ever conflict with anything you're going to encounter; 192.168.178.x would be another example, which would be the default for AVM Fritz!Box devices - and Xiaomi likes to use 192.168.31.x…).

15

Hmm, now I see this happens only with 21.x.x, never with my old 18.x.x routers.
I rebooted the 21.x.x router and sure enough, my Internet access went down for a minute or so.

There has to be a way to prevent this without changing the whole LAN.

16

Are you talking about a normal reboot with a normally functioning configuration (such that nothing is changing across the reboot)? A device rebooting should not affect anything upstream, but it would be expected of course for the stuff downstream of the device being rebooted.

Let's see your system diagram (a photo sketch on paper is sufficient). Further, let's see your config, and please also describe the specific symptoms of the network going down? For example, have you tried persistent pings to another device on the lan? on the internet? etc? Does this affect both wired and wireless devices? Any other clues?

Please copy the output of the following commands and post it here using the "Preformatted text </> " button:
grafik
Remember to redact passwords, MAC addresses and any public IP addresses you may have:

cat /etc/config/network
cat /etc/config/wireless
cat /etc/config/dhcp
cat /etc/config/firewall
1 Like
17

Hi,

You can setup a specific ip address from image builder

create a file
files/etc/uci-defaults/99_uci-default-network in your build folder:

uci -q batch << EOI
set network.lan.ipaddr='192.168.20.1'
commit network
EOI

Put the proper address

and change your build script to include it
make image PROFILE=ABCD ....FILES="files/"

1 Like
18

I think you missed this post:

1 Like
19

This was kind of my first reply…

1 Like
20

Yea, I'm really not sure how the OP gets some random IP, Failsafe doesn't do that (at least as I recall).

My thought was a leaking switch and an upstream device issuing an IP. Also, I'm confused on if the OP is sysupgrading in this process, or merely rebooting.

The description of the issue was quite unclear to me TBH.

21

Are you talking about a normal reboot with a normally functioning configuration
(such that nothing is changing across the reboot)?

Normal yes. Not sure what you mean by nothing is changing across the reboot. Do you mean am I making config changes to the router before rebooting? No.

In terms of this thread, I thought it was said that this could happen when the firmware first initializes, on the first boot after it's been written to the device. Fine, I felt that was acceptable.

Then I noticed that when I reboot it, normal reboots, this issue happens now and then and it's random. Random in terms of, I've not found any way to reproduce it reliably.

A device rebooting should not affect anything upstream, but it would be expected of course for
the stuff downstream of the device being rebooted.

That's why I'm posting about it, because it is affecting the network, it's conflicting with the main LAN gateway that is 192.168.1.1.

Let's see your system diagram (a photo sketch on paper is sufficient).

I'm not sure what you want me to show. It's a standard network.

LAN devices-->pfsense firewall-->provider modem-->Internet

describe the specific symptoms of the network going down? For example, have you tried
persistent pings to another device on the lan? on the internet? etc? Does this affect both wired
and wireless devices? Any other clues?

I've not tested wireless since most of the time, I'm not using it.
When it reboots, my own PC loses Internet access for 10-30 seconds or so. That's how I noticed it. Initially I didn't notice the correlation between rebooting router and loss of network.

When I reboot the router, I use three other servers on the same LAN to ping 192.168.1.1, 4.2.2.2 and the router itself so I know when it's rebooting and back.

I just rebooted the 21.x.x openwrt router now. No change to anything, just a simple 'reboot -f'.
Just prior, I opened three ssh sessions to different machines on the LAN.
One is pinging the openwrt router itself at 192.168.1.5.
Another is pinging 4.2.2.2 and another is pinging the local gw 192.168.1.1.

As the openwrt router reboots, 4.2.2.2 is timing out but am still able to ping 192.168.1.1.
I know it's not the openwrt router responding because I can no longer ping it since it's rebooting.

They key however is that this ONLY happens when I reboot this openwrt 21.x.x router.
And it doesn't always happen. I rebooted it again and that time, no changes.

I did it a third time, this time pings stopped to 4.2.2.2 and 192.168.1.1 and I can always tell when RDP loses access which it did to a remote server I'm constantly using. The loss started maybe 15 seconds into the reboot. First both 4.2.2.2 and 192.168.1.1 stopped responding then 192.168.1.1 responses but the Internet was unreachable. Maybe 20-30 seconds later, the Internet was reachable again.

BTW, I've got those pings continuously running to see if there is any obvious Internet access loss and I'm not seeing any unless I reboot this router.

Why this affects Internet access is a mystery to me right now but this only happens with the new version of openwrt. I have other openwrt routers here that I play here and have online doing different things and none of those affect the network. Those are all 18.x.x however.

To me, it's something to do with the built in 192.168.1.1 causing a conflict with the main firewall temporarily. Meaning, when it boots, it's doing something using 192.168.1.1 temporarily and is of course why I'm not able to ping it at 192.168.1.5 since the network config that I have is not yet running but something else is.

Please copy the output of the following commands

OpenWrt 22.03.3, r20028-43d71ad93e

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 device
        option name 'br-lan'
        option type 'bridge'
        list ports 'eth0.1'

config interface 'lan'
        option device 'br-lan'
        option proto 'dhcp'

config interface 'wan'
        option device 'eth0.2'
        option proto 'dhcp'

config interface 'wan6'
        option device 'eth0.2'
        option proto 'dhcpv6'

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

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

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

cat /etc/config/wireless

config wifi-device 'radio0'
    option type 'mac80211'
    option channel '1'
    option hwmode '11g'
    option path 'platform/10300000.wmac'
    option htmode 'HT20'
    option disabled '0'

config wifi-iface 'sta'
    option device 'radio0'
    option network 'wwan'
    option mode 'sta'
    option ssid 'xxx'
    option encryption 'xxx'
    option key 'xxx'
    option disassoc_low_ack '0'
    option disabled '0'

cat /etc/config/dhcp

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

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